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ABSTRACT 



The results of the second 18 months (December 15, 

1968 - June 30, 1970) of effort toward developing an Information 

Processing Laboratory for research and education in library science 
is reported in six volumes. This volume contains two parts. Part I 
includes: a user’s guide - a guide to writing programs to TMS 
(Terminal Monitor System) for information processing. Part II is a 
system programmer's guide to the internal structure of TMS itself. 

The information presented in Part II is of critical importance to 
anyone interested in expanding or modifying the existing capabilities 
of TMS. (Other volumes of this report are available as LT 003607 
through 003610). (Author/NH) 
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FOREWORD 



This report contains the results of the second 18 months (December 15, 
1968 - June 30, 1970) of effort toward developing an Information Pro- 
cessing Laboratory for research and education in library science. The 
work was supported by a grant ( OEG— 1-7-071085^286) from the Bureau of 
Research of the Offie^of Education, U.8. Department of Healthy Edu- 
c at 1 on , and Welfare and. -also—' by-^the-.Un lver s i ty of ^California . The 
principal investigator was M.E. Maron, Professor of Librarianship . 

This report is being issued as six separate volumes by the Institute 
of Library Research, University of California, Berkeley. They are: 

“ Maron, M.E. and Don Sherman, et al. An Information Processing 

Laboratory for Education and Research in Library Science: Phase 2 , 

Contents- — Introduction and Overview; Problems of Library 
Science; Facility Development; Operational Experience. 

* Mignon, Edmond and Irene L. Travis. LAB SEARCH : ILR Associative 

Search System Terminal Users 1 Manual . 

Contents — ‘Basic Operating Instructions; Commands; Scoring 
Measures of Association; Subject Authority List. 

* Meredith, Joseph C, Reference Search System (REFSEARCH) Users y Manual . 

Contents-- Rationale and Description; Definitions; Index and 
Coding Key; Retrieval Procedures; Examples. 

■ Silver, Steven S. and Joseph C. Meredith. DISCUS Interactive 
System Users T Manual . 

Contents — Basic On-Line Interchange; DISCUS Operations; 

Programming in DISCUS; Concise DISCUS Specifications; 

System Author Mode; Exercises. 

* Smith, Stephen F, and William Harrelson. TMS: A Terminal Monitor 

System for Information Processing . 

Contents — Part I: Users 1 Guide - A Guide to Writing Programs 

for TMS 

Part II: Internals Guide - A Program Logic Manual 

for the Terminal Monitor System 

Aiyer , Arjun K, The Cl MARON System: Modal ar Programs for the 

Organization and Search of Large Files . 

Contents--Data Base Selection; Entering Search Requests; Search 
Results; Record Retrieval Controls; Data Base Generation. 

Because of the joint support provided by the File Organization Project 
( OEG-l-7-‘07l083“5068 ) for the development of DISCUS and of TMS,. the volumes 
concerned with these programs are included as part of the final report for 
both projects* Also, the CIMARON System, whose development was supported by 
the File Organization Project, has been incorporated into the Laboratory 
operation and therefore, in order to provide a balanced view of the total 
facility obtained, that volume is included as part of this Laboratory project 
report. (See Shoffner , R.M. , et al . , The Organization and Search of 
^ ographi c Records in On-Line Computer Systems: Project Summary . ) 
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PREFACE 



The cathode ray tube terminals of the Information Processing 
Laboratory are linked to a remote IBM 3&Q computer. This computer 
is run under the IBM Operating System, which allows several different 
users to share simultaneously the resources of the machine. This 
sharing is accomplished by establishing independent "partitions" 
of main memory and allocating one partition to each active program. 
The Operating System maintains control over and provides services 
to the individual computer programs residing in the various par- 
titions, This is on a one-to-one basis; ±,e., the Operating System 
allows but one program to be active in a given partition at any 
given time. 

Since this 3o0 is not dedicated to serving the Information 
Processing Laboratory, it is necessary that the entire network of 
remote terminals appear to the Operating System to be a single 
program residing in one partition. However, each remote terminal 
must be able to call forth and use individual programs independently 
of the simultaneous activity on other terminals . Thus , to serve 
the needs of the Information Processing Laboratory, there must be 
a means of running several independent programs simultaneously 
within a single partition that is under the- control of the Opera- 
ting System. 

To meet this need, the Institute of Library Research has 
developed the Terminal Monitor System (TMS). This is a system 
program which provides the software interface between the Operating 
System and applications programs running on individual terminals. 

It provides terminal programs with access to the services offered 
by the Operating System, and it also serves to represent the en- 
tire network as a single program to the Operating System, 

This two-part volume of the final report on the Information 
Processing Laboratory project describes the Terminal Monitor 
System, Part I, an application programmer’s guide to TMS, 
tells how to use TMS facilities to write on-line application 
programs that are to be run on the Laboratory network. Part II 
is a system programmer’s guide to the internal structure of 
TMS itself. The information presented in Part II is of critical 
Importance to anyone interested in expanding or modifying the 
existing capabilities of TMS, 
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PART I 



A GUIDE TO WRITING PROGRAMS 
FOR TMS 
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1 . INTRODUCTION 



This manual Is intended for use by programmers writing appli- 
cation programs to be run under the Terminal Monitor System (TMS). 
As such, it gives a brief overview of system design and details the 
programming conventions to be employed when using this system* as 
well as the specifications for employing the system macro in- 
structions, It also describes an elementary top-level terminal 
control language that allows the user at a terminal to identify 
himself (i.e., "log in") to the system , specify the problem pro- 
gram that he wishes to work with, and recover from program errors. 

A much greater level of detail regarding system design, the actual 
expansion of system macro instructions, and details on the system 
processing modules is contained in a companion publication, the 
TM5 Internals^ Guide. 



This manual assumes on the part of the problem programmer a 
moderate level of proficiency in writing Assembler Language pro- 
grams to operate under 08/360, This should include basic Assem- 
bler Language programming and the use of the Supervisor Services 
and Data Management Services macro instructions. Specifically, 
this manual assumes a working knowledge of the contents of the 
following publications: 



a . 


System 


b* 


os /360 


c , 


os /360 


d. 


os /360 


e , 


os /360 


f . 


os/360 

Form Ci 


g* 


03/360 



lions, Form C 28 - 66 U 7 
1,1 Criteria Used in Design 



Several basic criteria have governed the de gn of TMS. Pri- 
mary among these has been the need to fit the system into rather 
a small amount of main storage (compared to systems with similar 
capabilities). Of nearly equal importance has been the need to 
maintain complete compatibility with the IBM Operating System 
(OS/360) with minimal (hopefully none) alterations to OS code. The 
system has to be able to service the several users on the individual 
terminals in a quas i - s imul t ane o us manner and give these users the 
options of running different application programs or sharing the 
same application program with little or no consideration as to 
what the other users of the system may be doing at that particular 
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time. As a corollary , the system has to remain as immune as pos- 
sible to crashes by individual application programs and maintain 
service to the remaining terminals while attempting to recover 
from any problems encountered. Due to the past history of XLR 
equipment acquisitions and possible changes in the future, the 
system must he able to deal with different types of terminals inclu- 
ding a mixture of keyboard and cathode-ray tube (CRT) terminals. 
Insofar as is possible, the potential effects on the application 
programmer of having to deal with different types of terminals 
should be minimized. Finally, an elementary form of top-level con- 
trol language was found necessary to perform such housekeeping func- 
tions as the identification of authorized users and the loading of 
programs at their request. 

The above criteria, in addition to consideration of the avail- 
able manpower and resources, resulted in the following primary de- 
sign decisions. First, the amount of monitor code in main storage 
at execution time had to be minimized; thus all setup and shutdown 
functions had to be separated out from this code and assembled as 
separate load modules to be in main storage only during setup and 
shutdown processes. The need for OS compatibility and maximum 
reliability required a system that would stand between the user 
and OS/36O and edit all requests by application programs to reduce 
or eliminate the possibility of system crashes in trying to serve 
these requests. It was decided that as much as possible of the bur- 
den of checking a user’s service request for validity would be placed 
on the assembly phase of application program development by building 
extensive checking facilities into the various TMS macros and thus 
eliminating the need for execution time checking in many eases. 
Finally, space and manpower requirements dictated that while the 
system exhibit certain features commonly found only in so-called 
time-sharing systems or in OS/MVT the system itself would not be 
designed in this manner, thus, the system design achieves a level 
of complexity somewhere between the dedicated application telepro- 
cessing system and the full time -sharing system. 

These primary design decisions led in a fairly natural manner 
to certain secondary design decisions. Since on a small computer 
or in a small multi -programming partition the greatest problem 
likely to occur is running out of space, first priority had to be 
given to detecting the impending occurrences of this problem and 
avoiding them. Since the most uncontrollable situation with respect 
to core allocation generally arises with the execution of an OS OPEN 
macro instruction certain steps had to he taken to minimize the 
possible adverse effect of using this macro. One of the most impor- 
tant was in pre-loading all of the necessary access method subroutines 
into the TMS partition prior to starting execution of TMS, To mini- 
mize the amount of core used up in this manner it was decided to 
use only the basic access methods and to restrict availability to 
a “subset of basic access methods services which would adequately 
serve the various application programmers. With the loading of 
access method subroutines under control, and the possibility of 
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automatic 'buffer allocation greatly reduced by limiting ourselves 
to basic access methods, most of the remaining core allocation 
problems became easily predictable and could be handled by doing 
conditional GETMAXN's. Further, to minimize the amount of code 
necessary to set up an OPEN macro instruction, the data sets were 
limited to direct access data sets already allocated and cataloged 
in the system catalog* Thus data set availability could be readily 
checked and most data set parameters would be obtained from the 
various data set control blocks (D3CB f s), 



To allow TMS to deal with many different types of terminals 
in a relatively uniform manner with minimal investments in special 
programming the Basic Teleprocessing Access Method (BTAM) was se- 
lected as the interface between TMS and the various terminals * 

It was realized that most TMS functions would keep control of 
the computer or at least keep control of the TMS partition for the 
whole time that they were executing; thus most TMS modules needed 
only to be serially reuseable, For those situations where conflict 
would exist between two or more user programs attempting to use 
the same serially reuseable resource a simple queuing scheme employ- 
ing a single chain of TMS ''Function Blocks" was devised, (See 
page 8 for a discussion of Function Blocks [FB's].) 

1,2 Basic Structure of the System 

To the application programmer, the Terminal Monitor System (TMS) 
is l) a collection of tables or blocks linked to each other and con- 
taining all information about the system; and 2) a set of processing 
routines which operate on these tables and programmer-supplied pa- 
rameters to perform the necessary system services. Another part 
of the system is a top-level supervisor, the phantom job , which 
handles certain basic console operations. The application program- 
mer's only interface with the phantom job is the fact that the phan- 
tom job calls the application program as a subroutine of itself. 

There Is a monitor routine for each of the major functions 
performed by TMS, plus some routines not directly accessed by the 
application program. Interface between the program and the monitor 
is accomplished by the use of special TMS macro instructions. 

The basic block upon which the rest of TMS depends is the 
Communication Region (CR)* To the application programmer, the 
prime use of this block is as a vector of entry point addresses 
to the monitor routines * There is only one CR for the entire system. 

The basic block for each terminal is the Function Block (FB ) . 
This block contains such things as: an auxiliary save area for the 

application program associated with the terminal; the user identi- 
fication code for the user logged in at that terminal; the appli- 
cation program name; the terminal number; several bytes of flags 
denoting terminal type and terminal and program status; pointers 
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to other control "blocks in TMS ; terminal I/O information and -work 
areas ; and pointers to chains of the main storage "blocks and OS 
Data Control Blocks associated with that particular terminal. 

For each terminal attached to the computer there exists a 
Buffer for terminal input/output* For terminals that share the 
same communications link, these "buffers are chained together and 
shared between those terminals * Thus it is not safe to assume that 
a particular I/O "buffer address will always be associated with the 
application program during the period that it is in operation. 

1.3 Services Provided 

The Terminal Monitor System provides several services to facil- 
itate the writing of application programs that will operate in a 
multi “programmed environment interacting with their users via re* 
mote terminals connected to the computer by communications lines 
and employing 5 if necessary* direct access data sets. These ser- 
vices generally take the form of one or more TMS macro instructions* 
which set up parameters and then transfer control to a suitable 
portion of the TMS monitor. The necessary tables to control the 
system and each application program running under it are also pro* 
vided. Finally TMS provides an elementary top-level terminal con- 
trol language to enable the housekeeping functions of user "log in ,T 
and specified application program loading to be performed. 

There are several operations that each application program 
must perform in interfacing with the TMS such as obtaining new save 
areas * linking save areas, establishing "base registers* and main- 
taining, if desired, pointers to various system tables. The macros 
provided for this purpose are TMS SAVE and TMSRETN . 

Central to the operation of a multi— programming system is the 
ability for an individual application program to indicate that it 
no longer requires control of the computer until some asynchronous 
operation is completed, such as i nput / output . In TMS this function 
as well as the function of synchronizing program operation with 
these asynchronous operations is performed by the TMSWAIT macro 
instruction. 

In a dynamic multi -programmed environment such as TMS, care- 
ful management of the main storage of the computer is necessary. 

In order to free system resources as soon as possible after it is 
determined that the application program no longer needs them (espec- 
ially in the case where the user has lost control of his application 
program) it is also necessary to keep careful record of what areas 
of main storage are allocated to which application program. Both 
of these functions are embodied in the TMSGETM and TMSFREEM macro 
instructions which are used for obtaining and releasing main storage, 
respectively. 





The Terminal Monitor System provides access to bodies of ex* 
ternal data by any of the three basic access methods for data pro- 
vided under OS- Sequential , Direct , and Indexed, In addition, 
certain functions of the Queued Indexed Sequential Access Method 
are simulated by TMS via the TMS3ETL, TMSGET, and TMSESETL macro 
instructions , 

It Is desirable both to simplify the manner of obtaining 
access to data sets and to avoid the kind of errors that may re- 
sult in the entire monitor run being abnormally terminated. In 
addition, the tables associated with data sets are often one of 
the, leading obstacles to writing re-entrant programs , The TMSOFEN 
macro Instruction combines the function of both the OB DCB and 
OPEN macro instructions . This macro instruction actually gener- 
ates a DCB in specially obtained main storage and returns the 
address of the opened DCB to the user program. The corresponding 
macro TMSCLOSE is responsible for closing the data sets and freeing 
those areas of core obtained for the DCB and associated buffers. 



2, SYSTEM CONVENTIONS 



2,1 Use of Saire Areas and Initial Base Registers 

In the use of save areas and initial base registers the Term- 
inal Monitor System conforms almost exactly to the standards of 
OS/ 360 , Upon entry to the application program a save area s which 
is to become the top of a save area chain, is pointed to by reg- 
ister 13 (RS). Subsequent save areas must be linked to this save 
area using OS conventions and register 13 must point to a valid 
save area at all times* The only variance from standard OS prac- 
tice is that the first word of each save area contains the address 
of the associated FB. As each save area is obtained, its first 
word must therefore receive the contents of the first word of 
the preceding save area. Code for maintaining this convention 
and the linkage between save areas is generated as part of the 
expansions of the TMSSAVE and TMSRETN macro instructions. These 
macro instructions also contain provisions for either providing 
an in-line save area, obtaining additional core storage for a save 
area, or suppressing the generation of any save area at all. 

As In all 03 programs, register 15 (RC) contains the entry 
point address when control Is passed to the user program. The 
TMSSAVE macro instruction generates code to move this address into 
a permanent base register of the user’s choosing. The default 
base register is register 12 (RB), 

When it is necessary to make maximum usage of every register 
available, the application programmer may wish to use register 13 
as a pointer to a general work area, of which the first 72 bytes 
are reserved for the save area. In this case he may specify 
SA=REM0TE and employ the SAINCR operand to specify the number of 
additional bytes he wishes obtained. If this increment plus the 
72-byte save area is greater than U095 bytes , a level b warning 
message will be Issued, but the necessary code will be generated* 
In this case, It is the application programmer ' s responsibility 
to provide additional base registers as needed. 

2,2 Use of FB and CR 

Upon entry to an application program from the top level mon- 
itor, a pointer to the program’s Function Block (FB) is provided 
In register 11 (R9) and a pointer to the general Communication 
Region (CR) Is provided in register 10 (R 8 ), Certain TMS macro 
Instructions generate code to alter byte settings in the FB; the 
FB may also be used to locate the CR if a pointer to the CR is not 
being maintained by the user program. The CR is principally used 
by application programs as a vector of addresses of monitor rou- 
tines . 



With respect to the FB , the application programmer has the 
option of stating whether the program will or will not maintain 
register 11 as the FB pointer. The application programmer may 
encode RFB^NONE in the TMSSAVE macro instruction to indicate 
that register 11 is not guaranteed to contain a pointer to the 
FB at all times. If this is not coded, register 11 must point to 
the FB whenever any code generated hy a TMS macro Instruction Is 
being executed. With respect to the CR pointer , the application 
programmer may specify any register (including register 10) to 
he the CB pointer by using the RCR operand of the TMSSAVE macro 
instruction. If this operand is omitted, it is assumed that no 
CR pointer will he maintained hy the program. If the application 
programmer does specify a register as a CR pointer, he must in- 
sure that it contains the proper address whenever code generated 
hy a TMS macro instruction is executed. 

A set of standard register equates and symbolic definitions 
for the FB and CR are maintained on ILR.MACLIB. These may he 
obtained hy the COPY REGS, COPY FB, and COPY CR statements, respec- 
tively. The register equate, FB, and CR definitions must he pro- 
vided for every program that employs any TMS macro instruction, 

2.3 Obtaining and Releasing Main Storage 

In order to prevent system crashes due to running out of 
main storage and to properly clean up after an application pro- 
gram failure, TMS must maintain control over all main storage 
allocations within its partition. The macro instructions used to 
obtain and release main storage are almost identical to the Retype 
GETMAXN and FREEMAXN macro instructions in OB. 

To obtain core storage, the TMSGETM macro instruction is used. 
Its only parameter is either a symbolic expression representing 
the number of bytes to be obtained or the designator, in parentheses, 
of a register which contains the count of bytes desired. The sym- 
bolic expression form of operand may be used only to request U 095 
bytes or less. Upon return from TMS, register 1 (RPl) points to 
the address of the storage obtained. 

The macro instruction used to release main storage, TM3FREEM, 
differs from FREEMATN, its OS counterpart, in that it requires 
only one operand; the address of the area of main storage to be 
released* This parameter is supplied as either the symbolic address 
of a full word of storage containing the address of the area to 
be released, or the designator, in parentheses, of a register con- 
taining the address of the area to be released* The length of 
the area to be released Is obtained by TMS from a link element 
that it maintains. This approach results in the restriction that 
any area of main storage obtained by TMSGETM macro instruction 
must be released by a corresponding TM8FREEM macro instruction; 
i.e,, no area of main storage obtained as a single unit may be 
released in segments. 
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2.^ Opening and Closing Data Sets 



The operations of defining, opening, and closing data sets 
in TM3 are considerably different than the corresponding opera- 
tions in OS. TMS takes advantage of the fact that all data sets 
are already defined and allocated on direct access storage de- 
vices with complete information in their data set control blocks 
(DSCB^s), Thus TMS has no need for an analogue for the OS DOB 
macro instruction. Instead the few parameters needed to complete 
the definition of a data set are supplied as additional operands 
in the TMSOPEN macro instruction. 

For direct access (DSORG^DA) data sets the following options 
are supported: READ, WRITE, CHECK, searching by block identifi- 

cation, and searching by key. For indexed sequential data sets 
(DSQRG-IS) the following options are supported: READ, WRITE, 

UPDATE, and CHECK, The GET, SETL, and ESETL macros are simulated 
by corresponding TMS macro instructions, TMS does not presently 
support general access methods for update so there exist no ana- 
logues for PUT or PUTX, For partitioned data sets (DSORG-PO) the 
following options are supported: READ and WRITE (NOTE and POINT 

are implied). For sequential data sets (DSORG— PS ) the following 
options are supported: READ, WRITE, CNTRL, and POINT, 

A data set in TMS is both defined and opened by use of the 
TMSOPEN macro instruction. Several of the operands of this macro I 

instruction have the same purpose and meaning as their counter- 
parts in the OS DCB macro instruction. These include DSORG, MACRF, ; 

EODAD, OPTCD, 5YNAD, EOEA, PCIA, SIGA, CENDA, and XENDA, Of the j 

foregoing only the DSORG and MACRF operands are required. Since 

TMS speaks strictly in terms of data sets , the operand D5NAME is j 

used in TMSOPEN instead of the operand DDNAME that is used in the j 

08 DCB macro instruction. This operand, which is required, spec- * 

ifiee the major portion of the data set name. Its parameter con- 
sists of from 1 to 8 EBCDIC characters with no embedded blanks j 

or periods. In searching for the data set this name will be J 

appended to the qualifier XLR. , and may be further qualified by 1 

user or terminal- dependent information* This additional quail fi- j 

cation is controlled by the QUALIFY keyword operand; some form of < 

additional qualification must be supplied for any output data set, j 



Specifying QUALIFY =BYNAME causes a period followed by the user's \ 
identification code to be appended to the data set name. This \ 
should be used for data sets which must be keyed through an in- | 
dividual user (such as DISCUS restart files). By specifying | 
QUALIPY^BYFBNO the problem programmer causes the characters TI *FB ?t j 
to be appended to the data set name followed by the two digit ) 



terminal number (which is unique for every terminal in the system) . 
This form of qualification is most useful for data sets which are 
not to be associated with a particular user but which must be 
guaranteed to be unique within the system at any given moment 
(such as off-line print files), 

O 

ERIC 



I 
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In addition to obtaining storage for* and creating, the user’s 
DCB, the system will proceed to obtain storage for 1 buffer and 
insert the proper pointers into the DCBBUFCB address pointer, 
DCBBUFCB will point to a standard OB 8-byte buffer control block 
followed immediately by one buffer of the proper length as indi- 
cated in the BLKSIZE information stored in the DSCB, The acquis- 
ition of this buffer by TMS may be suppressed by encoding the 
operand BUFFKRS-NO, in which case the program will he responsible 
for supplying its own buffer area. 

Certain information usually supplied as OPEN macro instruction 
parameters in OS is supplied in TMS by use of the FOR keyword 
operand. This operand indicates for what type of processing the 
data set is being opened. The permissable forms of this parameter 
(not all of which apply to every data set organization) are INPUT, 
INCUT, QUTXN, OUTPUT* and UPDAT , Each of these parameters has the 
same result as specifying the corresponding parameter in an OB OPEN 
macro instruction. 

The problem programmer has some measure of control over the 
processing of any errors that occur during the data set location 
and opening process. The default option is to go to TMSPURGE to 
terminate the entire program. By specifying the RETURN=YES operand, 
the user programmer may receive control hack from the system with 
an appropriate completion code in register 15 (RC ) . 

For all forms of data set organization, the EXCP access method 
may be specified with or without appendages. 

2.5 Terminal I/O 



Coimnuni cat ions he tween an application program and a remote 
terminal are handled by the macro TMSCSIO. This macro supports 
several different methods of specifying messages for output, the 
basic read and write operations to the terminal* a set of device- 
dependent operations (such as screen erase or typewriter carriage 
return) and the choice of an immediate or deferred wait. 

2,5*1 Write Operations 



The message to he written is specified as the first positional 
operand in one of three ways*. ■ l) the message text itself may be 
provided, enclosed in apostrophes* 2) a symbolic address of the 
message may be provided; or 3) the designator (enclosed in paren- 
theses) of a register which contains the address of a message may 
be provided. The fact that this is a write operation is specified 
by encoding WRITE as the first subparameter of the OP parameter. 

The second and succeeding subparameters indicate additional device 
dependent operations to be performed with the write. For cathode 
ray tube (CRT) devices these include EBW for erase screen before 
write, and/or NL for the new line before write. For mechanical 
typewriter-type terminals RBW for carriage return before write 
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and/or RAW for carriage return after write may "be specified. De- 
vice-dependent operations for both CRT’s and typ evr i t e r- 1 yp e term- 
inals may be specified in the same write operation- the system will 
determine which type of terminal is being serviced and ignore any 
operation specified for the other type of terminal. This feature 
may be used to obtain a measure of device independence in problem 
programs * 

Messages to be written may appear in one of two formats. 

Format 1 consists of a half-word count of the number of characters 
in text followed immediately by the text itself. Format 2 con- 
sists of the text alone ; a separate character count is provided 
elsewhere. If the message is a Format 2 message s its length must 
be provided in the LENGTH operand. The LENGTH parameter may be 
either a symbolic expression whose value is the message length 
(1,021 bytes or less) or a register designator (in parentheses) 
of a register which contains the length count. Absence of any 
LENGTH operand indicates a Format 1 message. 

2.5.2 Read Operations 

Read operations are specified by coding READ as the first 
positional subparameter of the OP parameter. Upon conclusion of 
the input-output operation, register 1 (RPl) points to the first 
character of the text read. Register 0 (RPO) contains a, count 
of the number of characters of incoming text. Thi^ cowrit in- 
cludes the end of transmission (EOT) character which appears as 
the last non-blank character in the buffer, 

2.5.3 Additional Features 

The problem programmer may overlap console I/O with other 
operations if he desires. Use of the WAIT-DEFER operand allows 
processing to continue simultaneously with console input -output * 

A separate TMSWAIT macro instruction must be coded by the appli- 
cation programmer to wait for the completion of console I/O. 

Coding WAIT=IMMED causes a call to TMSWAIT to be generated imme- 
diately following the call to the console I/O routines this is 
also the default option. If it is desired that return be made to 
a point other than the instruction immediately following the 
TMSOSIO macro instruction, the programmer may provide a symbolic 
address by using the RET keyword operand. Transfer is then made 
to this address upon return from TMS, 

2,6 Non-Terminal I/O 

Input/output to user’s data sets is accomplished by using the 
standard OS macro instructions with the restriction that only those 
macro instructions and/or operands that are supported by the TMS 
system may be employed. (For a discussion of whlfn access methods 
are supported, see "Opening and closing date set" above.) The 
only exceptions to this rule are the following: (l) TMSWAIT must 
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"be used in place of any WAIT or WAITR macro instruction; (2) if an 
OS CHECK macro instruction is employed the macro instruction 
TMSWAIT must immediately precede it , specifying the same DECB, 

2,7 Scheduling and Event Synchronization 

The release of the partition so that other TMS users may use 
the CPU and the synchronization of program processing with I/O 
events is accomplished in a vay completely analogous to that of 
OS, In order that TMS may maintain complete control of the sit- 
uation and make maximum utilization of the available resources, 
a special system macro called TMSWAIT is employed. The ECB key- 
word operand provides the symbolic address of the event control 
block on which the application program is to wait. The default 
specification is FBECB, which is used for waiting on terminal 
I/O operations. An optional keyword operand RET may be used to 
provide the symbolic address of the next instruction to be 
executed following return from the wait* Absence of this operand 
indicates that the next instruction to be executed is that imme- 
diately following the TMSWAIT macro instruction. 

Certain forms of terminal I/O require processing following 
the completion of the wait for I/O to complete* Thus , another 
keyword operand , OP, is used to indicate what form of console I/O 
we are waiting on. The permissible parameters for this operand 
are READ, WRITE, CLEAR, and REWRITE* Depending upon TMS require- 
ments, additional code may he generated following the branch to 
the wait routine* 



3. SPECIFICATIONS FOB CODING TMS MACROS 



3.1 TMS CLOSE ~ Close a Data Set 

The TMSCLOSE macro instruction causes the specified data set 
to be closed and the main storage for the DCB and buffers (if sup- 
plied by TM80FEN) to be released* 



[symbol ] 



TMSCLOSE 



(data control block register) 
data control block address 



Data control block register 

is the symbolic or literal definition of a register which 
contains the address of the data control block to be closed. 
If (l) or (RFl) is designated, register 1 must contain the 
DCB address prior to invoking the macro instruction* 

Data control block address 

is the symbolic address of a full-word which contains the 
address of the data control block to be closed. 

3.2 TM3CSI0 -- Terminal Input/Output 

TMSCSIO macro instruction causes an input or output operation 
to be initiated at the terminal associated with the function block 
pointed to by register 11 (RFB), Depending upon the parameters 
of this macro instruction, a separate TMSWAIT macro instruction 
may be necessary to test for completion of the operation. 



[symbol ] 



TMSCSIO 



^n-esbage' ^ 
Umessage register )i 
(^message address / 



[HEAD 

OP = ( J WHITE / 
f CLEAR | 

(rewrxtej 

[» option] , ) 

[, LENGTH- (length register ^ 
(length express! any ] 

[ ,HET=return address ] 
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Message 

is the message to he transmitted by a WRITE operation. The 
LENGTH parameter must not be coded. 

Message register 

is the symbolic or literal definition of a register which 
contains the address of a Format 1 or Format 2 message which 
is to be transmitted by a WRITE operation. If (l) is design 
nated, register 1 must contain the address of the message, 
(Bee section 2,5 for description message formats,) 

Message address 

is the symbolic address of a Format 1 or Format 2 message 
which is to be transmitted by a WRITE instruction, 

OP = READ - read from the terminal 
WRITE - write to the terminal 
CLEAR - erase screen (CRT’s only) 

REWRITE - no meaning at present (for planning purposes only). 



Option 

is one of the following: 

EBW - Erase the contents of the screen before writing (CRT’s), 
RAW - Return the carriage after transmitting the message 
(Typewriters ) - 

BBW - Return the carriage before transmitting the message 
( Typewriters ) • 

NL - Start the message on a new line (CRT’s), 

Length register 

is the symbolic or literal designation of a register which 
contains the length of a Format 2 message. If (0) is desig- 
nated, register 0 must contain the length of the message. 

Length expression 

is any expression suitable for use in an LA instruction which 
represents the length of a Format 2 message. 



WAIT-IMMED 

causes generation of a call to the wait routine as part of 
the macro expansion, 

WAIT=DEFER 

causes no generation of a call to the wait routine, A sepa- 
rate TMSWAXT macro instruction is necessary. 
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Return address 



is the symbolic address to which control is to he returned 
after execution of the macro instruction. If omitted, con- 
trol passes to the next instruction in sequence. 

3.3 TMSPL1T! — Delete a load module 

The TMSDLETE macro instruction causes the responsibility- 
count for the load module specified to be decreased by one s and 
when the responsibility count reaches zero the core occupied by 
the module is released and the request block dropped from the load 
list. The module must have been loaded via the TMSLOAD macro in- 
struction . 

The corresponding user load list is updated, and the area occu- 
pied by the load list element for this module is freed. 

If the request specifies a name that is not on the user load 
list, the requesting program is purged. 

The TMSDLETE macro instruction is coded as follows: 



[symbol ] 



TMSDLETE 



EPNAME = entry point name 
EPLOC = address 



j 



where : 

1 entry point name- 

is the legal entry point name as specified in the TM8LQAD 
macro instruction. 

! address T 

is the symbolic address (or register containing this 
address) of an entry point name. 

3 . b TMSESETL — End Sequential Retrieval (QISAM Input only) 

The TMSESETL macro instruction ends the sequential retrieval 
of data from an indexed sequential data set, and causes the buffers 
associated with the specified data control block to be released. 

A TMSESETL macro Instruction, or an end of data set indication must 
separate TMSESETL macro instructions issued for the same data con- 
trol block. 
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The TMSE8ETL macro instruction is written as f ollows : 



[symbol] 



TMSESETL 



deb address 



deb address 

is the address (or register specification containing this 
address) of the data control block for the indexed sequential 
data set being processed* 

3.5 TMBFREEM — Release Main Storage 

The TMBFREEM macro instruction causes a block of main storage 
obtained by TMSGETM to be released* 



[symbol] 



TMSFREEM 



A = (storage address register)* 



Storage address register 

is the symbolic or literal definition of a register containing 
the address of the block of main storage to be released, 

3.6 TMSGET — Obtain Next Logical Record (QISAM input) 

The TMSGET macro instruction causes the monitor system to re- 
trieve the next record and to return the main storage address of 
the record in register 1, Control is not returned to the problem 
program until the operation is complete. 

The TMSGET macro instruction is written as follows : 



[symbol] 



TMSGET 



dob address ^ 

(address register) 



deb address 



is the address of the data control block for the data set 
being retrieved, 

(address register) 

is the specification in parentheses of a register containing 
the data control block address. 
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NOTE: 



When control is 
should be tested for 


returned to the problem program 9 register 0 
a completion code as follows: 


If Reg 0 is : 


Reg 1 points to: 


F r 0 r 


Logical Record 


F f 4* 


message: "Record with specified key does 
not exist 1 


F ! 8* 


message: f I/O errors" 



NOTE : 

For QISAM under TMS , the TMSOPEN macro instruction must specify 
BUFFERS^NO - 

3,7 TM8GETM — Obtain Main Storage 

The TMSGETM macro instruction causes a variable -length block 
of main storage to be allocated to this terminal. The address of 
this block is returned in register 1. The programmer may specify 
that control passes back to the calling program in the event of 
error , 



[ symbol ] 


TMSGETM 


™ ((length value register)^) 

~ ~ (_ length value express ion) 5 












^ U 





Length value register 

is the symbolic or literal definition of a register which con- 
tains the size in bytes of the desired block of main storage - 

Length value expression 

is an expression whose value represents the size in bytes of 
the desired block of storage. When specified in this manner , 
the size must not be greater than 4095 bytes. 

RETURN = NO 

indicates that control passes to the PURGE routine of the 
monitor if insufficient main storage is available, 

RETURN = YES 

indicates that control returns to the calling program under 
' all circumstances . The return code in register 15 is as follows : 

Return Code Meaning 



0 

4 



The main storage requested was allocated. 
No main storage was allocated. 



3-8 TMSHDCPY — Provide Hard Copy of CRT Output 

The TMSHDCPY macro instruction provides the facility to ob- 
tain a permanent copy of console I/O operations via the use of 
the lU03 line printer* 



The output to the printer recognizes all carriage control 
characters inherent in the data and as many of the format charac- 
ters as feasible. 

The TMSHDCPY macro instruction is coded as follows : 



[symbol] 



TMSHDCPY 



ME3 - address * LENGTH 



= Hregister) / 
/ address \ 






where : 



MES = address 

T address 1 is the symbolic specification of the address 
(or register containing this address) of the start of 
the text to be output. If this operand is omitted, the 
text on the entire screen will be read and copied. 

LENGTH = address 

Address* is the symbolic or absolute specification of 
the length of the text to be output. f (address register) 1 
is the specification j in parentheses, of a register con- 
taining this length. If MES is not coded, this operand 
need not be. 

The TMSHDCPY routines will return a return code in register 15 
as follows : 

0 - processing completed normally 
08 - processing partially completed, not enough core 
12 — no processing done, not enough core 

3.9 TMSLOAD — Bring a Load Mod\\le into Main Storage 



The TMSLOAD macro instruction causes the monitor system to 
bring the load module containing the specified entry point into 
main storage if a usable copy is not available. The responsibility 
count for the load module Is increased by one. Control Is not 
passed to the load module; instead, the main storage address of 
the designated entry point is returned in register 0* The- load 
module remains in main storage until the responsibility count is 
reduced to zero through the use of the TMSDLETE macro instruction. 
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The TM 3 L 0 A-D macro instruction is -written as f ollows s 



[ symb oi ] 



TMSLOAD 



f EFNAME = symbol < 

EFLOC - address of name < 



EPNAME = 

is the entry point name in the load module to he brought into 
main storage, 

EPLOG = 

is the main storage address of the entry point name described 
above. The name -will be padded with blanks to eight 'bytes 
if necessary. 

When control is returned from the TMSLOAD macro instructions 
register 15 contains a return code as follows : 

0 — successful load 

k - not enough core to load program 
8 - module missing from library 
12 - module non-reentrant and already loaded 
16 - I/O error reading module directory 

3,10 TMSLOG — Create an Entry in the System Log 

The TMSLOG macro instruction will create an entry in the system 
log for the requesting program. It is ejected that the program 
will want to create information of its own within this entry; 
therefore 3 provision is made for up to 202U bytes of user informa- 
tion to be written# 

Each entry into the log is prefaced by a 1 6 byte leader as 
follows : 



Bytes : 


2 


2 


u 


8 


Field: 


LEE 


FBNG , 


FBNAME 


FBPNAME 



where : 

LEE is the total length of the entry including header 

FBNO. is the number of the terminal which had control when 
the request was issued 

FBNAME is the name of the uaer logged in on that terminal 








FBPNAME is tile name of* the program that was requested by the 
terminal user (not necessarily the name of the pro- 
gram issuing the macro) 

Records are written RECFM^V and the BDW and KDW created by the system* 
The TMSLOG macro instruction is coded as follows : 



[symbol] 



TMSLOG 




message 

message 



addressj, LEN 



number 



where : 

f message ! 

is a literal string of the actual entry to be created 
message address 

is the address (or the specification in parentheses of 
a register containing the address) of the log entry to 
be created* 

number 

is the absolute or symbolic designation of the length 
(or the specification in parentheses of a register con- 
taining this length) of the entry to be created. Do not 
include length of leader. If this operand is omitted, 
or set to zero, only the 1 6 byte leader is written. 

Only the combinations listed above are valid for the TMSLOG macro 
instruction. 

Upon return, register 15 (RC) contains a return code as follows t 
0 - normal completion. 

08 - DCB has not been opened (report to TMS system con- 
sultant ) . 

12 - length supplied by processing program was invalid. 

16 - not enough core was available for creation of the 
entry. 

3.11 TMBGFEN -- Generate Data Control Block and Open a Data Set 

The TMS OPEN macro instruction causes the system to obtain core 
for and generate a data control block for the data set named. Un- 
less suppressed, one buffer is also provided preceded by a standard 
buffer control block pointed to be DCBBUFCB, The program may spec- 
ify that it is to receive control with a completion code in regis- 
ter 15 (RC) in the event of an error. Upon normal completion, the 





newly-* generated DCB is pointed to by register 1 (KPl) - If* 
BUFFERS-YES was specified, register 0 (RPO) points to the buffer 
provided * 



[ symb ol ] 



IMS OPEN 



DSNAME = data set name, DSGRG = data set 
organisation code, 

MACRF = (macro reference code [,.«.]) 



[ ,QFTCD = (option code)] 

[jSYNAD = synchronous error address] 
[ s EODAD = end-of-data address] 




Data set name 

is a one- to eight- character name that will become part of 
the data set name used to search the system catalog and disk 
volume tables of contents for a corresponding pre- allocated 
data set. The basic set name generated will be of the form: 

ILR * nnnnnnnn 

where nnnnnnnn represents the name supplied as this parameter. 
Data set organization code 

is a two-or-three-character code representing the organi- 
zation of the data set. The permissable codes in TMS are: 

DA , PAU - Direct access 

IS - Indexed sequential 
PO,POU - Partitioned 
PS ,PSU - Sequential 



Macro reference code 



is one of the combinations ‘belc^, depending on data set organ- 
ization and, access method: 



Character Definition 




a W 



K 



KI 



[c]) 



(R 




QISAM 

{(GL[,S[k]])> 



c 


CRTRL 


p 


POINT (implies ROTE) 


R 


READ 


W 


WRITE 


Character 


Definition 


C 


CHECK (absence de- 
notes WAIT) 


I 


Search to be made by 
block identification 


\ K 

\J 


Search to be made 
by key 


1 R 


READ’ 


W 


WRITE 


Character 


Definition 


C 


CHECK 


R 


READ (implies 
FREEDBUF) 


U 


Records are bo be 
updated. If U is 
coded with R s U must 
be coded with W. 


Character 


Definition 



GL 



K 



(NOTE: 



GET (Address of buffer 
to be provided by the 
control program 

Search to be made 
by record or 
generic key 

SETL 

For QISAM, TMSQPEN must 
specify BUFFERS - NO ) 



O 
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[ ] indicates optional character ; select one from vertical stack 
within { select one or none from vertical stack within []. 
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BP AM 

(H) ) 

(W) ( 

(R,V7)j 

Option code 



Character Definition 

R READ (implies NOTE 

and POINT) 

W WRITE (implies NOTE) 



specifies optional services to be performed. These are a sub- 
set of the services available under OB. The permis sable 
combinations in TMS are: 



BEAM 



[W] [E] 




Character Definition 

A Specifies that actual device 

addresses are to be presented 
("block address" operand) in 
READ and WRITE macro instructions . 



E Requests an extended search (more 

than one track) for block or 
available space. Ignored if A 
is also coded. Refer to IBM 
manual "Supervisor and D.M. Macro 
Inst." for the discussion of 
the LIMCT operand for a descrip- 
tion of extended search. 

F Specifies that when feedback is 

requested in a READ or WRITE 
macro instruction, the device 
address returned is to be of the 
form presented to the control 
program. If F is omitted, feed- 
back is in the form of the actual 
device address of the block, 

R Specifies that relative block 

addresses are to be presented 
("block address" operand) in 
READ and WRITE macro instructions. 

W Requests a validity cheek for 

■write operations. If the device 
is a 2321 data cell, validity 
checking is always performed, 
whether requested or not . 



[ ] Indicates optional character; select one or more from vertical 
stack within [ ] * 
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If neither R nor A is coded, relative track addresses are assumed. 



BPAM 

W 



BSAM 

U 

w 

wo 



Character Definition 

W Requests a validity cheek for 

write operations. If the de- 
vice Is a 2321 data cell, va-* 
lidity checking Is always per- 
formed, whether requested or 
not , 



Character 

U 



W 



Definition 

Printer with Universal Char- 
acter Set feature only — un- 
blocks data checks and allows 
analysis "by an appropriate 
error analysis (SYNAD) routine. 
If U is omitted, data checks 
are blocked (not recognized 
as errors ) , 

Direct access device only 
— requests a validity check 
for write operations. If the 
device is a 2321 data cell, 
validity checking is always 
performed, whether requested 
or not. 



Synchronous error address 

has the same function as in the OS BOB, 

End-of-data address 

has the same function as in the OS DOB, 

FOR = INPUT 

Indicates an input data set. 

FOR « OUTPUT 

indicates an output data set, 

FOR = INOUT 

Indicates an Input data/set initially and, without reopening, 
an output data set. 



FOR = OUTIN 



indicates an output data set initially and, without reopening, 
an input data set. 



O 
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FOR - UPDAT 



indicates a data set to be updated in place. 

BUFFER - YES 

indicates that TMS is to provide a single buffer of the nec= 
ess ary length. 

BUFFERS == NO 

indicates that the application program will provide its own 
buffers . 

QUALIFY = BYNAME 

indicates that the final data set name generated will be: 

ILR , nnnnnnnn , xxxx 

where nnnnnnnn is the name specified by the DSNAME operand 
and xxxx is the user identification code for the current 
user of the program. 

QUALIFY = BXFBNO 

indicates that the final data set name generated will be: 

ILR . nnnnnnnn . FBxx 

where nnnnnnnn Is the name specified by the DSNAME operand 
and xx is the terminal number for the current user of the 
program. 



RETURN - YES 

indicates that in cash of an error during TMSOPEN processing* 
control is to be returned to the calling program. The contents 
of register 15 (RC) indicate results of the OPEN as follows: 



R eturn code 
0 



k 



8 

12 

RETURN = NO 



Mf aning 

Successfully located and opened. 

Unable to locate the data set in the 
system catalog or in the volume table 
of contents of all DASD f s on which 
it resides . 

Insufficient core remains to complete 
open processing. 

Disastrous error during open processing. 




indicates that in case of an error, control is to be returned 
to the monitor. 



3,12 TMSPRINT — Put a line to line printer 

The TMSPEINT macro instruction causes a line to be printed on 
the off-line printer. All output using this macro instruction is 
clearly identified by a header preceding it. 



[symbol] 


TMSPRINT 


C area address / 






1 (address register )f 



where : 

area address 

is the address of a 133 byte line to be printed* whose 
first character is the ASA printer control character* 

(see Appendix 3); 

( address register) 

is the specification of a register which contains the 
address of the line to "be printed* 

3*13 TMSRETN — Eeturn to calling program 

The TMSRETN macro instruction causes the restoring of the 
registers which were saved hy TMSSAVE when the program was entered* 
Control is then returned to the calling program, (i.e., the moni- 
tor). If TMSSAVE obtained main storage for a new save area, then 
TMSRETN will release this storage. 



[symbol] 



TMSRETN 



3.1^ TMSSAVE -- Entry from calling program 

The TMSSAVE macro instruction causes the establishment of a 
control section with the symbol in the name field being used as 
the control section name* It generates code to save all regis- 
ters In a standard save area, establish a new save area if de- 
sired, and establish a base register* If a register is designa- 
ted as a communication region pointer, code is generated to load 
that register* If a remote new save area Is called for, code is 
generated to obtain core storage for that save area; otherwise, 
the new save area is generated In-line. 
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[symbol ] 


TMS SAVE 


[RBASE= base register] 






[ 


5 RFB=N0NE ] 






[ 


^HCR-CR pointer register] 






[ 


*RW0RK- work register] 








(local"'') 








*sa^Jnoni £ 

( REMOTER 

,SAINCR= length increment] 



Symbol 

is the name of the control section and entry point of the user 
program. 

Base register 

is the symbolic or literal designation of a register to be 
used as the first base register. If omitted* register 12 (RB) 
is ass ume d * 



RFB = NONE 

indicates that the program will not maintain register 11 (R9) 
as the pointer to the associated FB, 

CR Pointer register 

is the symbolic or literal designation of a register that 
will contain the address of the communication region when- 
ever a TM8 macro instruction is invoked. If omitted* no 
such register is established and all TMS macro instructions 
generate slightly slower code. Upon entry to the user pro- 
gram* register 10 (r 8) contains the communication region 
pointer , 

Work register 

is the symbolic or literal designation of a register that 
will be used as a work register for establishing save area 
linkage. If omitted* register 2 (R0) will be used. 



SA= LOCAL 

indicates that the new save area is to be generated in-line 
in the expansion of TMS SAVE . This makes the user program 
non-reentrant . 

SA^NONE 

indicates no save area provided. Programmer must provide his 
own. 
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3-15 TMSSETL — Set Lower Limit of Sequential Retrieval (QISAM 
input only) 

The TMSSETL macro instruction causes the monitor system to 
start processing the input request at the specified record. Se- 
quential retrieval of records losing the TMSGET macro instruction 
continues from that point until the end of the data set is encoun- 
tered or a TMSCLOSE or TMSESETL macro instruction is issued* A 
TMSESETL macro instruction must be issued between TMSSETL in- 
structions that specify the same data set. 

The TMSSETL macro instruction can specify that retrieval is 
to start at the beginning of the data set, at a specific record, 
or at the first record of a specific class of records. 

The TMSSETL macro instruction is written as follows: 



[symbol ] 


TMSSETL 


(deb address / 


/b 1 






((address register)] 


Ik, key address / 








/KC, key address 








l length) 



dob address 

is the address of the data control block for the data set 
being retrieved 

(address register) 

is the specification in parentheses of a register containing 
the data control block address 

B specifies to start at the beginning of the data set 

K specifies starting at the record with the specified key 

KG retrieve the first record of a specified key class 

key address 

Is the symbolic name of a main storage location (or a regis- 
ter containing this address) of the key of the record wished. 
In the case of type KG, this is the address of the partial 
key specifying the key class 

length 

is the length of the partial key given for the key class. 

This may be an absolute decimal, number, or the specification 
of a register containing the value right adjusted in binary. 
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3,1 6 TMSWAXT — Wait for an event 



The TMSWAIT macro instruction causes the user program to he 
dismissed until completion of the event associated with the desig- 
nated event control block. Only one event control can he waited 
on at a time by any user program. 



[symbol ] 



TMSWAIT 



[RGB - event control block] 
[ ,0P = operation code] 

[ ,RET = return address ] 



Event control block 

is the symbolic address of an event control block which con- 
forms to all the rules of a standard OS event control block* 
If omitted, FBECB (the terminal input/output event control 
block) is assumed. 

Operation code 

Is one of the following: 

READ - Upon completion of the wait, the terminal text length 
(including EOT character) is in register 0 (RPO) and 
the text address is in register 1 (PPl), 

WRITE - Wo effect, 

CLEAR - No effect, 

REWRITE - No effect. 

Return address 

is the symbolic address to which control is to he returned 
after execution of the macro instruction* If omitted, con- 
trol passes to the next instruction in sequence. 



4, THE TOP-LEVEL CONTROL LANGUAGE 



In order that TMS may deal -with a great many users and offer 
each user the choice of -which of many user programs he wishes to 
operate under, a minimum form of executive program is necessary. 

This program exercises complete control over the operation of the 
system and interfaces with the terminal user via the top-level con- 
trol language, Among the services provided by this top level 
supervisor are: the identification of a terminal user via the 

process of "logging in" ; the acceptance of a user program name, 
and the loading of the associated user program; the notification 
of the user when certain errors have occurred; and the ability to 
logically disconnect the individual terminal from the computer 
when necessary, 

4,1 Logging In 

When TMS first begins operation the following message is 
directed to each terminal: 

TMS 10 01 TMS IN OPERATION 

followed immediately by the message: 

TMS 101 A WAITING FOR LOGIN 

This latter message indicates that the supervisor is waiting 
for the user to identify himself at the terminal by typing in a 
user identification code of up to four characters (this code will 
have been assigned to each user by laboratory supervisory personnel)* 
The proper response to any request for input from the top level 
supervisor varies with the various types of terminals . For the 
Banders Associate CRT displays the following sequence must be 
followed; push the CLEAR button followed by the FORMAT TYPE button 
then type in the desired response (in this ease the user login 
code) and depress the SEND BLOCK button. There are several re- 
sponses to an attempt to login. The message: 

TMS 10 21 NOT ACCEPTED 

indicates that the user identification code provided is not accepted 
as valid. The message: 

TMS 10 31 NOT ACCEPTED, NAME ALREADY IN USE 

Indicates that while the user identification code supplied Is valid, 
a user at another terminal is already "logged In" under this code. 
After either of the above two messages the message: 

TMS101A WAITING FOR LOGIN 

Is reissued inviting another attempt to "log in" * If the user 
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identification code has been accepted as valid the message: 



TMS1Q2I NAME LOGGED IN 

is returned where name is the ‘user identification code as recog- 
nized, 

k.2 Specifying Programs 

Immediately after the message accepting the login the message: 
tmsioUa SPECIFY PROGRAM 

will appear. This indicates that the user is to respond with the 
name of the user program that he wishes to have loaded and assigned 
to his terminal. The names and purposes of the individual user 
programs are specified in a separate publication; each name will 
he at least 1 hut no more than 8 characters in length. There are 
several messages that may indicate difficulty in loading the re- 
quested program. The message: 

TMS107I PROGRAM NOT FOUND 



indicates that the name supplied is not the name of a program 
currently in the TMS library. The message: 

IMS 10 81 FRQGRAM NON-REENTRANT AND ALREADY IN USE* WAIT OR TRY ANOTHER 

has a more complex meaning. This message indicates that the pro- 
gram does exist hut that it may only he used by one terminal at 
a time and is already being used at another terminal. The user 
should wait until the other user has exited the program and repeat 
his request for the program or he should request another program 
that he can use in the interim. The final error message that may 
appear is : 

TMS109I NOT ENOUGH CORE TO LOAD PROGRAM 

This indicates that insufficient main storage remains in the com- 
puter to load the executable code of the program requested. Each 
of the above three messages is immediately followed by the mes- 
sage : 

TMSIOUA SPECIFY PROGRAM 



which invites the user to try again. In the event that the pro- 
gram is successfully loaded the next message will be generated 
by the user program itself. To understand the purpose of such 
messages users should consult the documentation of the individual 
user programs. Depending upon the individual user program and 
assuming that no errors have occurred in the operation of the user 
program in the interim the user will specify in some manner that 
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he wishes to exit from that user program and return to the top 
level supervisor. If this is done properly the message: 

TMSIOSi NORMAL EXIT FROM USER PROGRAM 

will appear followed by a report of the message: 

TMSIOUA SPECIFY PROGRAM 



this allows the user to specify a new program for execution or 
to leave the system* 

L,3 Logging Out 

The processing of Indicating to TMS the user has finished 
at this particular time and wishes to leave the system is called 
"logging out", The user is able to log out at any time when the 
last message appearing at the terminal is: 

TMS 10 LA SPECIFY PROGRAM 



Instead of specifying a program the user responds with the word 
LOGOUT* If this is correctly done the system will respond with 
the message: 

TMS 10 51 NAM! LOGGED OUT 

followed by the message: 

TMSIOIA WAITING FOR LOGIN 

which indicates that a new user may now sit down at the terminal 
and identify himself to the system, 

b,k Error Exits from User Programs 

If TMS detects some form of error in the user program that 
threatens the integrity of the system it will force that user 
program to cease execution and return control to the supervisor, 

A series of messages will be returned to the terminal. The first 
one or two messages will generally be preceded by a TMS message 
identifier with a number in the range 150-199- These indicate 
the particular form of error encountered and are summarized in 
Appendix 2. These specific messages are then followed by the more 
general message: 

TMS 110 I ABNORMAL RETURN FROM USER PROGRAM VIA PURGE ROUTINE 

Receipt of this message verifies that an error has occurred and 
that the program has been terminated, all main storage obtained 
by the program has been released, and all data sets opened by 
the program have been closed. This message is followed by the 



message : 



TMElOl+A SPECIFY PROGRAM 

which invites the user to restart the same program, start a new 
program, or "log out" from the system. 

k,5 Special Operations 



Under certain circumstances it 'becomes necessary to logically 
disconnect an individual terminal from the computer. This is best 
done only by persons with a thorough working knowledge of the sys- 
tem since at the current time this disconnection is irreversible. 
This operation may be performed only when the last message received 
from TM8 i s : 



TMS101A WAITING FOR LOGIN 

instead of responding with a user identification code the user 
responds with the word DISCONNECT. The terminal ceases operation 
at this point and no further message is received from the system, 
A confirmation is typed out at the computer; if there is any 
question about the success of the disconnect procedure the com- 
puter center operator may be contacted and requested to examine 
bis console printout, .When all terminals have been DISCONNECTed, 
the Terminal Monitor System will cancel itself. 
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Appendix 1: List of Permissible Macro Parameters 
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refer to macro-instruction 



APFOTDIX 2 

List of System Messages 



TMS 150 I - PROGRAM ENDED WITH STORAGE OR DATA SET STILL ATTACHED 

System action : Close all DCB's left and free all storage , 

Programmer response : Make sure that an exit from the program 

is not forced which leaves DCB T s open or 
storage still attached. 

TMS 151 I - INSUFFICIENT MAIN STORAGE LEFT TO SATISFY TMSGETM REQUEST 

System action : User purged. 

Programmer response : Wait until storage is freed by another 

program and try again * or reduce the amount 
of storage requested. 

TMS 152 I - TMSFREEM REQUEST DOES NOT SPECIFY LEGITIMATE ADDRESS 

System action : User purged. 

Programmer response : Make sure the program has not incorrectly 

modified its storage pointers* If this 
happens consistently, the program is prob- 
ably at fault; if erratically, report to 
system consultant* 

TMS 153 I - ATTEMPT TO OPEN AN UNAVA I LABLE/ UNCATALOGUED DATA SET 



The system has detected that the data set name specified in a 
TMSOPEN request is not catalogued or, if catalogued, is unavailable 
to the user because : 

1* The data set is qualified; 

2. The data set cannot be shared; or 

3* The data set does not exist 

4, An I/O error was discovered reading the catalogue or DSCB 

System action ; User purged. 

Programmer Response : In case (l), catalogue the data set; in 

ease (2) or (3), create or change the 
attributes of the data set. In case (4), 
report to the system consultant, 

TMS 154 I - INSUFFICIENT MAIN STORAGE LEFT TO COMPLETE OPOT OF A DATA SET 

System action - User purged 

Programmer response : Wait until l^ain storage is freed by another 

program and try again. 







TM5 155 I - DISASTROUS ERROR IN TMS OPEN 



The system has detected an unrecoverable error in the TMS OPEN 
processing* 

System action : , User purged. 

Programmer response : Make sure that the parameters supplied 

in the TMSOPEN macro instruction are 
consistent -with the attributes of* the 
data set* 

IMS 156 I - TMSCLOSE REQUEST DOES NOT SPECIFY LEGITIMATE ADDRESS 

The system has detected that the address supplied in a TMSCLOSE 
request is not the address of a DCB which was obtained via a TMSOPEN 
macro instruction* 

System action : User purged* 

Programmer response : Make sure the program has not incorrectly 

modified the register or area containing 
the address of the data control block, 

TMS 157 I - END OF DATA DETECTED WITH NO EODAD SPECIFIED 



An end of data condition has been detected with no end of data 
address specified in the data control block* 

Sys tern action : User purged. 

Programmer response : Modify the TMSOPEN request to include the 

EODAD parameter. 

TMS 158 I - SYNCHRONOUS ERROR DETECTED WITH NO SYNAD SPECIFIED 

A synchronous error condition has "been detected with no SYNAD 
exit specified in the data control block. 

System action ; User j .urged. 

Programmer response : Modify the TMSOPEN request to include 

the SYNAD parameter. 

TMS 159 I - INSUFFICIENT CORE LEFT FOR DEBUGGING 

The user specified that he wanted to use the debugging facility, 
but not enough core was available for this facility to be used. 

System action ; User purged. 

Programmer response : Wait until main storage is freed by an othe 

user and try again. 
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TMS ISO I - ERROR DETECTED IN TMS, USER PURGED WITH SNAP 

The system has detected a program error within itself. 

System action ; User is purged with a snap dump. 

Programmer response : none 

TMS l6l I - ERROR DETECTED IN TMS * USER PURGED ? SNAP UNSUCCESSFUL 

The system has detected a program error in itself. 

System action : User purged, snap dump vas unsuccessful. 

Programmer response : none . 

TMS lS2 I - ERROR DETECTED IN PROGRAM, USER PURGED 

The system has detected a program error in the user program, 
hut a debugging request was not specified. 

System action : User purged. 

Programmer response : modify program if error is known, or 

request debugging facility and try again, 

TMS 200 I - ERROR OCCURRED AT RELATIVE LOCATION 3QC5TCOXX: 

This message occurs in conjunction with one of the above as 
information for the programmer only in deciding where in the pro- 
gram the eiror occurred. 
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AFPMDIX 3 

Carriage Control Characters 
(lU03 line printer) 



b - Single space before printing 
+ — No space before printing 

0 - Double space before printing 
- — Triple space before printing 

1 - Eject to line 6 before printing 

2 - Skip to next 1/2 page (line #9 or # 3 &) 

3 - Skip to next 1/3 page (line #8, #26, or #44) 

4 - Skip to next 1/4 page (line #7 3 #21, #35? or #49) 

6 - Skip to line 66 before concave paper fold 

,7 - Skip to line 66 before convex paper fold 

8 - Skip to line 1 

9 - Skip to line 6l 

All other characters are interpreted as blank. 
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PART II 



A PROGRAM LOGIC MANUAL FOR THE 
TERMINAL MONITOR SYSTEM 





1. DETAILED SYSTEM STRUCTURE 



The structure of TMS closely parallels the structure of 08/360 
and other complex operating systems implemented on 360-type machines . 
The system consists of a set of tables and a set of processing modules 
(or sub -programs ) . There are several types of tables, each con- 
taining information on the current state of the system itself, the 
application programs running under it, and the computer’s resources. 
All tables can be located from other tables by a system of pointers. 
The processing modules have two principal tasks: to maintain and 

update the tables; and to request the IBM Operating System to per- 
form certain tasks; (i,e., transmit a message to a particular ter- 
minal) . 



The remainder of Section 1 will discuss the tables peculiar 
to TMS and the interrelationships of these tables. Subsequent 
sections will introduce the processing modules and deal with their 
operation in detail, 

1.1 Communication Region 

The Communication Region (abbreviated CR) is, in essence, the 
key table of the system. As its name implies , it facilitates system 
communication by combining in one place pointers to virtually every 
other table and processing module in the system. The CR is im- 
portant when a processing module must re-establish pointers to 
all systems tables, such as in processing I/O interrupts. The 
Communication Region may be located in one of two ways when no 
pointers exist: via the entry point TMSCRADR in the module 

TM8BEGIN; or by first locating a function block via word 0 of any 
save area and then using the back pointer to the CR found in the FB, 

The CR contains several entry point addresses, primarily to 
those processing modules which may be accessed directly by appli- 
cation programs by use of TMS macros. These are TMSWAIT, TMSCBIO, 
TMSFURGE, TMSPLGAD , TMSGMFM, TMS SNAP , TMSOPEN, and TMS CLOSE , 

Several CR entries are used in wait list processing. These 
are a pointer to the wait list itself, a pointer to the current 
last entry, and a halfword containing a count of bytes in the 
basic wait list. A dummy Event Control Block is kept in the CR 
to indicate that a shared resource for which some processing 
module is waiting has been freed. The head of the chain of func- 
tion blocks queued for a shared resource and the pointer to the 
chain of all function blocks are both maintained in the CR. 

Pointers to the Data Control Blocks (DCB’s) for the TMS Library, 

Snap, and Log Data Bets are kept in the CR, Finally, several 
bytes of flags and a Program Interruption Element (PIE) save 
area are maintained in the CR. 



1-2 Function Block 



The Function Block (FB) is the major system table associated 
with a particular terminal device. Another approach is to consider 
each FB to he associated with, a particular invocation of* an applica- 
tion program (either separate , or sharing the program with other 
FB 1 s ) . In this context * the top-level supervisor program may he 
considered to he a sort of 1 super-program, and any application program 
a sub-program of it . The FB maintains most of the information 
unique to a particular terminal device and the program that is 
controlling it currently. In addition, it maintains direct pointers 
to those tables used most often in communication between the appli- 
cation program and IMS, OS/SfiO, and the communication hardware. 

A major part of the FB is a 16— word save area used to save 
the contents of all general registers when the FB does not have 
control of the CPU (i,e. , is in TMS WAIT status). Individual 
byte fields are reserved for general FB flags, last-entry informa- 
tion, and FB queue flags. Pointers are maintained to the CR, the 
next FB on the chain of all FB’s, the next FB on the chain of FB’s 
for the same communication line, the next FB on the chain of queued 
FB f s, the start of the application program’s storage block chain, 
the start of the application program’s Data Control Block Chain, 
the Data Event Control Block for the associated communications 
line, and the attached communication buffer. 

Many comimmications-related items are kept in the FB. These 
include an Event Control Block for terminal I/O, the terminal list 
offset used to locate the entry for the associated hardware ter- 
minal, a copy of the polling/addressing characters for a multi- 
drop terminal, the BTAM relative line number , the terminal number 
in EBCDIC, the current operation code for a terminal read/write 
operation, and various line length and position counts. Finally, 
the 4-character user name and the name of the current application 
program are kept in the FB for accounting and control purposes . 

1.3 Wait List and Wait List Extension 

The wait list forms the hub of TMS operation and is the reason 
that TMS is able to multiprogram in a single partition. The main 
portion of the wait list is exactly what the name implies: a 

standard OS/ 3^0 multiple— event wait list. The wait list extension 
is the same length as, and immediately follows, the last position 
of the wait list itself. Each word of the wait list extension is 
associated with the corresponding word in the wait list and can be 
located by adding the wait list offset from the CR to the address 
of the wait list entry. The wait list and wait list extension both 
consist of a static (or fixed-length) component followed by 
a dynamic (or variable -length) component. 

Three distinct sections which must be recognized by the TM3WAXT 
routine actually comprise the wait list. The first section con- 
sists of points to specialized TMS Event Control Blocks. First 



comes an Event Control Block pointer for input from the operator's 
console, followed by a pointer to the queuing Event Control Block 
located in the CR. The corresponding entries in the wait list 
extension are not used. The second section consists of a pointer 
to each communication line Event Control Block. To indicate that 
these are line Event Control Blocks, the first "byte of the cor- 
responding word in the wait list extension is set to hexadecimal 
'FF'. These first two sections comprise the fixed— length com- 
ponent of the wait list. The third section consists of a pointer 
to an Event Control Block for each FB which is currently in wait 
status. This section varies in length as FB ’ s are added to or 
dropped from the list, so it is being reordered constantly . The cor- 
responding entries in the wait list extension point to the associated FB. 

1.1+ Teleprocessing Data Event Control Block 

The Teleprocessing Data Event Control Block (TDECB) is the 
major system table associated with a particular communication 
channel. As such, it can be shared by more than one communication 
terminal , and thus may be pointed to, and shared by, several FB's. 

The TDECB is the principal table used by 05/360. BTAM (Basic Tele- 
processing Access Method) to control all data communications ac- 
tivities . The first word of each TDECB, sometimes called the 
line ECB , is pointed to by the wait list. This is how TMS knows 
when a communication operation has completed. 

The first 1+0 bytes of the TDECB are a standard IBM GS/360 
BTAM DECB , The contents and uses of the fields therein are docu- 
mented in the IBM publications regarding BTAM, so they will not 
be described here. The remainder of the TDECB consists of fields 
specific to TMS. There are several pointers: one to the head of 

the chain of FB's associated with this TDECB; three to the various 
code translation tables for the particular class of communication 
devices served; and one to the terminal list , which is a list of 
entries giving the polling characters and control flags for the 
ppypy ai terminal devices associated with this TDECB. Several bytes 
and halfwords are used for both bit flags and counts that describe 
the type of communication devices being serviced; some of the 
devices' hardware parameters such as character capacity; and the 
current state of the communication channel and the terminals attached 
to it. Finally, a save area for some fields is provided for use 
when read polling must be interrupted for a write operation 
and then must be resumed. ~ 
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2, INTERNAL SYSTEM CONVENTIONS 



This section describes the various conventions that all IMS 
modules and all application programs must follow if IMS is to 
function properly. Each subsection describes a convention or 
several related conventions regarding a particular IMS function* 

2.1 Save Areas 

To the application programmer, the rules for using save areas 
are the same as for QS/360, except that the contents of the first 
word of the existing save area must be copied into the first word 
of a newly-obtained save area. This insures that Register 13 
will always point to a word containing the adc^ess of the rele- 
vant FB . 

To avoid confusion, each FB must have a separate chain of 
save areas associated with it. The first save area on this chain 
is obtained and formatted by the "phantom job” when it is entered. 
Since the phantom job is entered once for each FB and is completely 
re-entrant , the independence of the various save area chains is 
assured . 

Most TMS functions involve receiving a request from an appli- 
cation program, editing and checking the request for validity, 
and then requesting 08/360 to perform certain tasks in order to 
satisfy the original request. This approach requires the use of 
two save areas: one to save application program registers upon 

entry to TMS, and one to save TMS registers upon entry to OS/360. 
One of these save areas is provided by the >save area chain asso- 
ciated with the FB (i.e., the save area pointed to by register 13)^ 
the other save area is the first 1 6 words of the FB itself* In 
practice, a IMS processing module that is entered by an application 
program first saves registers in the usual manner while it locates 
the FB, It then moves the saved information into the FB save 
area and stores the contents of Register 13 at the end* The save 
area pointed to by register 13 is then free for use by GS/36Q , 

2.2 CR and FB Pointers 

As the two crucial blocks involved in every TMS activity, the 
CR and FB must be reachable in many ways. The CR and FB may be 
located under any of the following conditions: 

a. The TMS exe out i on-time monitor TMSEXEC is first entered 
from QS/360, The address of the CR has been placed in register 
1 (parameter register) by the TMS startup routine TM8HSKP. 

b , A TM8 processing module is called from an application pro- 
gram, Register 13 points to a save area, the first word of which 
contains the FB address. The FB contains a pointer to the CR, 



e. A module in TM5EXEC must operate upon all FB f s. The CR 
address is obtained from the entry point TMGRAPR in TMSBEG-XN * The 
chain of* all FB f s is found from CRFBCHN, and each FB is operated 
upon in turn* 

d . The communications transmission end routine TMSTREND is 
entered from TMSWAIT and must locate the FB corresponding to the 
terminal just contacted. The address of the TDECB block is known 
upon entry to TMSTRENB, This block has a pointer to the chain of 
all FB f s associated with that particular line. Each FB in this 
chain is checked until the one matching the last active entry in 
the BTAM terminal list is found. 



e. The Event Control Block (ECB) that an application program 
has been waiting on is posted complete , and TMSWAIT must return 
control of the machine to that program. Wien TMSWAIT locates the 
address of the proper ECB in the wait list, the corresponding 
word in the wait list extension points to the associated FB. 

f. A shared resource for which one or more FB f s are waiting 
has just become free, and the next FB to use it must be found. 

The CR address is known, and the CR points to a chain of queued 
FB f s. The dequeuing routine travels down this chain of FB f s 
until it locates the first FB whose queue flags indicate a need 
for the resource in question. 

2.3 Chain of Core Storage Blocks 

In order for IMS to "clean up" after an application program 
has gotten into trouble, it must be able to free all main storage 
obtained by that particular invocation of the application program. 
This process requires that the size and location of every block of 
main storage for a particular FB be known to the system. This 
is accomplished by a system of chaining together all blocks of 
storage. 



All storage that is requested directly by an application 
program is obtained through TMS, The system adds 8 bytes to the 
request as received from the application program and passes it 
on to OS/360. When the request is satisfied, TMS uses the first 
8 bytes of the storage block as a special chaining prefix as 
indicated in Fig. X. When an application program requests the 
freeing of main storage, IMS cheeks the chain to verify that the 
storage is actually associated with the program., 



2 . h Chain of Bata Control Blocks 

For a particular invocation of an application program that 
gets into trouble, TMS must have a method for closing all Bata 
Control Blocks (BCB*s) for the same reasons that require the ability 
to free all main storage blocks. The solution of this problem is 
quite similar to that employed for the main storage problem. 
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Every DCB for a data set that is opened by an application pro- 
gram is constructed by IMS in main storage freshly obtained for 
that purpose* Prior to the first byte of usable DCB information, 

TMS inserts a *+-byte prefix pointing to the next DCB for that FB 
and providing an offset to generate the true DCB address. The 
actual arrangement is shown in Figure B. The offset is a value 
which is subtracted from the address of the first byte following 
the *+-byte prefix to give the actual DCB address for use by 
OS/360, The length of the DCB is implied by bits within the DCB 
which describe the type of data set that it represents. 

2,5 Types of X /0 and Data Sets Supported 

The Terminal Monitor System supports a subset of all of the 
I/O options and data set* type supported by QS/ 36 O. This subset was 
chosen to give the broadest possible range of data set handling 
capabilities consistent with the basic objectives of IMS, For 
example, features unique to certain peripheral devices such as 
card readers, printers, and magnetic tapes were omitted since IMS 
is designed to deal with only direct storage device and communication 
terminals. The requirement that TMS retain all control over WAIT 
scheduling, as well as the stringent limitations on overall systems 
size dictate that TMS limit itself to only the basic (as opposed to 
the queued) access method. In general, these restrictions are en- 
forced by code in the TMSOPEN macro which refuses to recognize any 
options not allowed by TMS, 



Although it is not stated in any documentation available to 
the casual user, TMS does support the EXCP access method with or 
without appendixes. This access method, thus, is available for 
use by highly skilled personnel in implementing specialised or 
unique functions under TMS. The basic sequential access method 
(ISAM) is available along with CONTROL and NOTE/POINT features. 

The CONTROL feature is intended only for use in file positioning, 
and not for such specialised functions as line skipping on a 
printer or stacker selection in a card reader or card punch. The 
options permitted under BSAM include the control of data cheeks 
for a printer with a universal character set feature and the WRITE 
validity check. The basic direct access method (BDAM) is supported 
for searching by block ID and searching by key. The CHECK specifica- 
tion is also permitted. Optional services supported under BDAM 
include extended search, write validity check, feedback control, 
and the use of actual device addresses or relative block addresses 
in place of the standard TTR addressing scheme. The basic index 
sequential access method (BISAM) is supported only for reading 
and updating, the use of CHECK is also supported. No BISAM options 
are supported under TMS, Finally, the basic partitioned access 
method (BP AM) is supported for basic reads and write. The only 
BP AM option supported is a write validity check. 

As the preceding indicates, TMS supports the four basic 
types of data set organization: sequential, partitioned, index 

sequential, and direct. The sequential partition and direct 
data sets may be either movable or unmovable. The types of I/O 



processing support include INPUT, OUTPUT, INOUT, OUTIN, and UP DAT . 
These parameters have the same meaning as in the OS OPEN macro 
instruction - 

2.6 Queuing and Dequeuing 

The terminal monitor system contains some resources which are 
shared hy the application programs, hut which may not he used hy 
two or more programs simultaneously. The official IBM terminology 
for such a resource is "serially reusable." Rather than use the 
relatively complex ENQUE/DEQUE facility of OS/360, TMS incorporates 
its own fairly simple queuing and dequeuing facility. Enqueuing is 
primarily a function of the processing module which represents or 
controls the serially reusable resource in question. Dequeuing 
is primarily the responsibility of the TMSWAXT processing module. 

Two words in the CR and one word in each FB are used for queuing 
control. The various processing modules use the CR dummy ECB 
to indicate when a shared resource which is being waited for has 
become free. The particular shared resource, which is now free, 
is indicated by setting a bit, in addition to the completion bit. 

The CRQUEUE pointer points to the chains of queued FB 1 s . The 
first byte of this word, also known as the CR queue flag area, 
has a bit set on for every shared resource that is currently 
being waited for. In this respect, it is the logical OR of all 
the analogous fields in all FB f s. The FB queue pointer is used 
to point to the next FB on the queue. The first byte of this 
word, also known as the FB queue flag, will have only one bit set 
on (in addition to the end- of- queue bit, if necessary) which will 
indicate the particular resource for which the FB is waiting. 

These relationships are illustrated in Fig. 3. 

Placing an FB on the queue involves appending the FB to the 
end of the queue chaih , setting the proper bit in the FB queue flag 
area, and ORing this FB queue flag area with the CR queue flag 
area. When the processing module which is releasing a shared 
resource wishes to detect whether another FB requires this resource, 
it merely checks the CR queue flag area. The assignment of a new 
FB to the shared resource is accomplished by searching down the 
chain of queued FB T s until the first queued FB with the proper 
bit set on is located. This FB is then removed from the chain, 
but the bit representing the shared resource is not reset in the 
CR queue flag area. Since more than one FB may have been waiting 
for the resource, this bit is reset only when a search of the chain 
has failed to turn up any FB with the corresponding bit sets. 
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INTRODUCTION TO MODULE FUNCTIONS 



3-1 System Initialization 

System initialization consists of" setting up all the special- 
ized TMS system tables, opening certain system data sets, and 
loading several programs', principally IBM access method modules 
into upper core- With initialization completed, control is 
passed to the processing routines In the execution time load module. 
Three processing modules are involved in system Initialization. 

Two of* these, TMSHSKF and TMSBLGCK, comprise the system initiali- 
zation load module. The third module, TMSBEGIN, is a small pro- 
cessing module in the execution time load module, and it provides 
the main entry point to the execution time load module. TMSHSKF 
contains a great bulk of the code for system initialization. It 
performs all initialization operations except those that require 
information available only within the execution time load module, 
such as the entry point addresses of the various execution time 
processing routines. TMSBLOCK is the basic skeleton for. most of the 
TMS tables- It is a separate processing module, so that any 
changes in the configurations of communication devices serviced 
by TMS may be accomplished merely by reassembling TMSBLOCK. Among 
the tables for which skeletons are provided in TMSBLOCK are FB f s, 
TDECB's, DCB T s for all communication lines and system data sets, 
all communication buffers, all terminal lists, and all transla- 
tion tables. TMSBLOCK has three entry points: the entry point 

TMSBLOCK, which points to the first word of the skeleton; the 
entry point TMSBLGTH, which is a word containing the length of 
the skeleton in bytes; and the entry point TMSLSTFB, which points 
to the start of the last FB skeleton assembled which will be the 
head of the FB chain. 

The TMSBEGIN module performs the last few steps associated 
with system initialization and then turns control over to the 
TMSWAIT module to begin executing each FB in turn. It too has 
three entry points: TMSBEGIN, which is the entry point to the 

final initialization code and by extension to the entire time load 
module; TMSCRAD.R, which is single word containing a pointer to 
the CR for use by any other execution time processing module that 
needs it; and TMSSYSV, which is a standard 18 word save area used 
to save the register contents upon entry to the execution time load 
module - 

3.2 Wait Handling and Dequeuing 

All wait list handling and scheduling of the next FB to gain 
control of the CPU is handled by the processing module, TMSWAIT. 

It is intended to be the only module that ever relinquished its 
control of the CPU to a lower priority partition- Since the TMS 
dequeuing method employs a pseudo-ECB, TMSWAIT is responsible 
also for locating the next FB that requires the shared resource 
and for passing control to the relevant processing module. TMSWAIT 
has two entry points: the entry point TMSWAIT, which is used for 



entry from application programs; and the entry point TMSDWAIT, 
which is used for a direct entry to the wait module from other pro- 
cessing modules- The two separate entry points are necessary be- 
cause direct entry into the wait module does not involve saving 
register in an FB. 

3.3 Communications with Computer Operator 

The TMSCNSL is responsible for the receipt and execution of all 
co mm ands from the central computer operator and the reissuing of 
the WTOR to reset IMS for the receipt of the next command. Any 
other processing module may transmit a message to the computer 
operator , as long as it does not wait for a response*, The TMSCNSL 
routine has two entry points: TMSCNSL, which is entered from 

TMSWAIT when the console ECB indicates that a message has been 
received from the central computer operator; and TMSREADY, which 
is entered from TMSBEGIN to complete system initialization by 
issuing the first WTOR of the TMS run. 

3*h Communi c at ions with Terminals 

All transmission of messages to and from remote terminals is 
handled by two processing routines. The first, TMSCISO, is used 
for the initiation of all terminal input /output operations. The 
second, TMSTREND, is entered from TMSWAIT when OS/ 360 indicates in 
one of the line ECB T s that some terminal I/O operation has been 
completed. This routine performs all operations associated with 
the completion of terminal I/O. TMSCISO performs such operations 
as determining whether or not the communication line is currently 
free, queuing the operation if it is not; selecting the buffer; 
performing code translation for outgoing messages; setting up the 
TDECB for the transmission; and invoking OS/360 BTAM to initiate 
the actual I/O operation. It has four entry points: TMSCISO, 

which is entered from an application program or another processing 
module to initiate reading or writing; TMSWRDEQ, which is entered 
from TMSWAIT to initiate writing by an FB just removed from the 
FB queue, where it had been placed until the line became available 
for a write operation; TMSRDRST , which is entered from TMSWAIT to 
restart a read polling operation on a multi -terminal line inter- 
rupted for a write transmission to one of the terminals; and 
TMSCSXOR, which attempts recovery from certain types of transmission 
errors . 

The TMSTREND routine performs such operations as checking for 
transmission errors, performing code translation on incoming mes- 
sages, and determining which terminal originated an incoming 
message so that it may post the I/O operation complete in the ECB 
for the proper FB» It has one entry point, TMSTREND. 

3.5 Obtaining and Releasing Prime Storage 

All obtaining and releasing of prime storage for application 
programs is handled by the TMSGMFM processing routine. This rou- 



O 




tine maintains the system convention regarding the chain of core 
storage blocks for each FB and performs validity checking against 
this chain . It also preserves the integrity of TMS by converting 
an application program’s unconditional request for primary storage 
to a conditional request for primary storage on behalf of the moni- 
tor system. Thus, it retains control of the situation if the re- 
quest for storage cannot be honored by OS/ 360 . This routine has 
a single entry point, TMSGMSM; the type of operation desired is 
determined by its parameters. 

3.6 Locating, Opening, and Closing of Data Sets 

There are two classes of data sets in TMS: system data sets 

and application program data sets. System data sets include the 
TMS library, snap and log data sets, and all communication lines. 

By their very nature , their requirements are known in advance, and 
they are opened by the TMSHSKP routine. The remainder of the data 
sets are opened and closed in response to requests from application 
programs. Since the opening and closing of data sets offer many 
opportunities for system crashes, all of this activity is performed 
for application programs by two processing routines: TMSOPEN and 

TMSCLOSE . 

TMSOPEN performs such functions as checking that a data set 
of the proper name exists and that all volumes containing it are 
available to the system; checking that all volumes listed as 
containing the data set have a proper entry for that data set; ob- 
taining primary storage for and constructing a DCB for that data 
set; maintaining the system convention of a chain of DCB’s for the 
application program’s FB; forming a JFCB for the data set (since 
the TMS deck does not include a DD card for every data set); ob- 
taining primary storage for a buffer if necessary; and Issuing the 
OS/360 OPEN macro for the data set and verifying the successful 
completion of the open process. This routine has one entry point, 
TMSOPEN . 

The TMSCLOSE routine performs such functions as: checking 

request validity; issuing the OS/360 CLOSE macro; freeing any 
buffer space obtained by TMSOPEN; and removing the DCB from the DCB 
chain and releasing the primary storage that had been obtained for 
it. It has two entry points: TMSCLOSE, which is entered from an 

application program; and TMSPCLOS, x^hich is entered from the 
TMSPURGE routine to close data set with a slightly different parameter 
structure and no validity checking. 

3.7 Loading Requested Programs 

Since the loading of user requested programs can result in sys- 
tem aborts if (l) the program requested is not present or ( 2 ) insuf- 
ficient primary storage remains to accommodate the program within 
the TMS partition, the processing routine TMSPLOAD is used. TMSPLOAD 
performs the following functions: executing an OS/360 BLDL macro 

to insure that the desired load module exists and to obtain Its length 



itL bytes; searching the FB chain for an already loaded copy of the 
same program which is re-entrant (thus insuring that additional 
primary storage will not he required); testing to insure that there 
will he sufficient primary storage for hoth the program to he loaded 
(if necessary) and the load routine; and invoking the OS/360 
LOAD macro instruction to complete the loading process. This 
routine has one entry point, TMSPLOAD. 

3.8 Recovery from User Program Errors 

When a running application program has caused an error con- 
dition which is detected hy one of the TMS processing modules, and 
the application programmer himself does not provide for recovery 
from this error situation, TMS must terminate the application pro- 
gram so that all system resources used by. that application program 
again are made available for the remainder of the system. It is 
also highly desirable that the terminal user be notified in a 
uniform manner of the various types of errors. All these func- 
tions are performed by the TMSPURGE processing routine. This rou- 
tine specifically performs the following functions: the closing 

and fraying of all attached DOB 1 s ; the releasing of all primary 
storage obtained by the application programs; the locating of the 
topmost save area on the save area chain; the issuing of a suitable 
error message selected from a table of error messages by a parameter 
to the purge routine; and the returning to the phantom job module 
(TMSPJOB) to indicate an abnormal exit from the application 
program. It has a single entry point, TMSPURGE. 

3.9 Top Level Control 

In a system where there is a choice of many different applica- 
tion programs , there must be a top level control program which 
handles the initial dialog between the terminal user and the 
system. Such a program invokes the various programs in response 
to the user’s request and handles the transitions between not 
only application programs but also successive users at the same 
terminal. To maintain simplicity and flexibility, this particular 
program is not considered a processing module like the remainder of 
TMS, but rather is treated as just another application program. 

The only difference between this and other application programs 
is that it has been loaded as part of the system initialization 
process , and all the FB save areas have been preset to return to 
the entry point of this program as if it has just called TMSWAIT 
to wait on an event which is now complete. One of the names that 
has been coined for this pseudo application program is "phantom job," 
and from this the program module takes its name, TMSPJOB. Some 
of the functions performed by TMSPJOB are: issuing the initial 

sign-on message to each terminal when TMS begins operation; re- 
questing, receiving, and verifying the user’s identification code 
as part of the job in process; requesting and receiving the name 
of the application program that the user desires to employ; 
calling TMSPLOAD to bring the program into primary storage; 
initializing the FB for use of the TMSBEBUG routine if the user so 
desires; passing control to the requested application program and 
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eventually receiving control back from the program by either a nor- 
mal or an abnormal return; logically disconnecting the terminal 
from the system at the user's request; and accepting the user's 
log-out when he is finished and conditioning the system to accept 
the log-in of a new user from the same terminal. This routine has 
one entry point, TMSPJOB. 
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DETAILED MODULE DESCRIPTIONS 



h.. 

k . 1 IMSBEGIN Module 

The TMSBEGIN module has three entry points* The main entry 
point is TMSBEGIN, which is used to initiate TMS execution time 
processing and which becomes the main entry point of the load 
module TMSEXEC. The entry point TMSCRADR obtains the communication 
region address if it cannot be located by -any other method. The 
entry point TMSSYSSV is used to gain -access to the TMS system save 
area if other modules need to reach it. 

This module customarily receives control by being transferred 
to and from TMSHSKP by means of an XCTL macro instruction. As is 
customary, it does a standard OS SAVE macro instruction and 
links the main TMS system save area to the save area pointed to by 
the system, TMSEXEC has provided the pointer to the communication 
region (CR) in register 1 (RPl). This address is now moved to 
register 10 (RCR) and installed in the area pointed to by TMSCRADR. 

A vector of entry point addresses to the various TMS processing 
modules is maintained at location ADDRVEC. This consists of a 
series of V-type address constants in the same order as defined in 
the CR dummy section (DSECT) . The length of this address vector 
is found as the value of AVLENGTH. This address vector is moved 
to the first part of the communication region by means of a single 
MVC instruction. 

Since certain serially reusable system resources may be re- 
quested by more than one applications program at the same time, a 
queuing methodology is supported. The key to signaling when a 
resource has been freed is the queuing event control block. The 
address of this event control block is placed in the second position 
of the wait list at this time. This procedure is explained in 
detail in the description of the TMSWAIT module. 

The only function left in the monitor initialization process 
is the issuing of a ready message to the console typewriter by 
means of a WTOR macro instruction, so that the operator may exercise 
control over the system from his console typewriter. Since this 
process is one that is repeated every time the operator employs 
the console typewriter, a branch is taken to the special entry point 
TMSREADY in the TMSCNSL module. 

b.2 IMSBLOCK Module 

The purpose of the TMSBLOCK module is to assemble itself into 
the terminal block skeletons and associated pointers for use by the 
TMSHSKP module. This module has three entry points: the entry 

point TMSBLOCK represents the beginning of the combined terminal 
block skeletons; the entry point TMSLSTFB provides the address of 
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the last FB generated in the TMSBLOCK module; and the global char- 
acter variable &PREVFB is used to obtain the name of the last FB 
generated by the FORMFB macro. 

The principal portion of terminal block skeleton generation is 
performed by repeated calls of the FORMFB macro. Details on this 
macro’s parameters and the code that it generates may be obtained 
from the section entitled ’’Use of the FORMFB Macro . ” All invocations 
of FORMFB should be placed between the headings "START OF MACRO 
CALLS TO DEFINE TMS BLOCKS" and "END OF MACRO CALLS TO DEFINE TMS 
BLOCKS" with no other intervening macro instructions, machine 
operations, or assembler pseudo-instructions which alter the loca- 
tion counter placed within this area. Following the area in which 
TMS blocks are defined come the various translation tables which 
are needed to convert code from the internal EBCDIC to the various 
transmission codes employed by the different communications de- 
vices . Each table is 256 bytes long and is labeled with the 
characters IECT followed by the four characters used in the INTRAN, 

OUT TRAN , or INTRLC keyword operands of the relevant FORMFB macro 
instruction . 

b . 3 TMSCLOSE Module 

TMSCLOSE is a service module of the Terminal Monitoi System 
designed to close down user files. It begins with a standard store 
multiple of the user’s registers into the save area he has provided. 

The function block of the user is located, and the register is 

copied, from his save area into location FBSAVE in the FB. The 

address of the data control block (DCB) is copied from register 1 

into register RDCB ; register RDCB is then used to provide addressability 

for the dsect IBADCB . The chain of DCB ’ s is then checked to make 

sure that this DCB address is on that chain. Location FBDCBCHN 

in the FB is checked for zeroes. If it is all zeroes, then the 

chain is empty, and a branch is taken to location DISASTER. The 

chain, if not empty, indicates the presence of DCB ’ s . In this 

case, the address of the DCB chain is loaded into register RPREV 

at location TESTDCB1, register RWORK is cleared, and the control 

word for the next DCB is loaded into register RW0RK2 from the 

location currently pointed to by register RPREV. Register RW0RK2 

now points to the control word in front of the next chained DCB. 

(See description of TMS OPEN for construction of DCB.) The nega- 
tive offset at this address is loaded into register RW0RK1 and 
used to compute the true address of the start of the DCB. This 
address is then compared to the address given on entry to the pro- 
gram. If equal, this is the DCB the user wished to close, and con- 
trol is passed to location TESTDCB2. Otherwise, register RPREV is 
loaded from the address to which it currently points. This step 
will give the address of the next DCB. This address is checked for 
zeroes. Zeroes here indicate that there are no more DCB ’ s chained 
to this FB. If this is the case (an incorrect DCB address passed 
to TMSCLOSE), a branch is taken to location DISASTER. Otherwise, 
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since the address of .the next chained DCB is in register RPKEV , a 
"branch is taken hack to location TESTDCB1 to test the next DCB. 

At location TESTDCB2 the location DCBMACRF in the DCB is tested for 
indications of a QlSAM DCB. If this was a QISAM DCB, the module 
TMSGTSLE must he deleted. If this was not, a branch is taken to 
location CLOSE. 

At location CLOSE an 0/S CLOSE macro instruction is issued, 
specifying the location of the DCB. The next task after closing 
the file is to free the core obtained for this DCB. To do this, 
location DCBBUFCB is tested for the presence of a hexadecimal 01. 

If it is present, it implies the existence of a buffer pool con- 
nected to this DCB which also must he freed along with the core of 
the DCB itself. If it is not present, a branch is taken to location 
FREEDCB. Assuming there is a buffer pool connected to this DCB, 
the pointer to this buffer pool is picked up from location DCBBUFCB 
and placed in register RPTR . The number of buffers in the buffer 
pool is picked up from four bytes off the address currently in 
register RPTR and placed into register RCTR . The number of buffers 
(now in register RCTR) is multiplied by the buffer size which is 
found at six bytes off the address currently in register RPTR. 

The alignment of the buffers is tested by testing location DCBBFALN 
for the presence of a hexadecimal 01, which indicates fullword 
instead of doubleword alignment. If location DCBBFALN does not 
contain a hexadecimal 01, there is doubleword alignment, and a 
branch is taken to location BUFFER1 . If buffer alignment is on 
a fullword, register RCTR is incremented by and control then 
falls through to location BUFFER 1 . At location BUFFER 1 the length 
of the buffer pool currently in register RCTR is incremented by 8 
to account for the buffer control block. This length is placed 
into register RPO , and the address of the buffer control block 
currently in register RPTR is placed into register RP1, and an 0/S 
FREEMAIN macro instruction is issued to free the core for the buffer 
pool. Control then falls through to location FREEDCB. 

Once the core for the buffer control block and the buffer pool 
have been released, the task is to free the core for the data con- 
trol blocks themselves. Since the length of a data control block is 
dependent upon the access method, location DCBMACRF must be tested 
to find the access method used. At location FREEDCB in the program, 
location DCBMACRF in the user's DCB is tested for the presence of 
a bit indicating the EXCP access method (DCBBITE) . If this bit is 
not present, a branch is taken to location FREED CB1 . Assuming this 
access method is EXCP, register W0RK1 is loaded with a value of 56* 
(This is 52 bytes for the EXCP DCB plus four bytes for the chain 
word.) Location DCBMACRF is then tested for the presence of a bit 
indicating that appendages were needed for this access method. If 
this bit is not present, a branch is taken to location FREEDCB5 . If 
it is present, register W0RK1 is incremented by 20 bytes, and a 
branch is taken to location FREEDCB5 - 



At location FREEDCB1 , location DCBDSORG is tested for the 
presence of a hit indicating an index sequential data set 
(DCBBITIS). If this bit is not present, a branch is taken to 
FREEDCB2. Ass umi ng the bit is present, register RW0RK1 is loaded 
with a value of 244 for the 236 bytes of the ISAM DCB , plus four 
bytes for the chainword, plus four bytes used by TMSGTSLE. A 
branch is then taken to location FREED CB5 . 

At location FREEDCB2 location DCBDSORG is tested for the pre- 
sence of a bit indicating the direct access method (DCBBITDA) . 

If this bit is not present, a branch is taken to location FREEDCB3. 
Otherwise, register RW0RK1 is loaded with a value of 92 for the 88 
bytes for the direct access data control block plus 4 bytes for the 
chainword. A branch is then taken to location FREEDCB5 . 

At location FREEDCB3 location DCBDSORG is masked for the pre- 
sence of a bit indicating the physical sequential access method 
(DCBBITPS) . If this bit is not present, location DCBDSORG does 
not contain a valid bit representation of the access method. A 
branch is then taken to location DISASTER. If this is a physical 
sequent! all data set, register RW0RK1 is loaded with a value of 92 
for the 88 bytes for the data control block plus the 4 bytes for 
the chainword. At location FREEDCB5 the DCB chain is updated by 
moving 3 bytes from the area pointed to by register RBLOCK (which 
contains the address of the data control block immediately following 
the one just closed) and moved to the address contained in register 
RPREV. This action completes the chaining of the previous data 
control block to the succeeding data control block. Register RPO 
is loaded from register RW0RK1 which contain^*' ' ? f_ " 5 of the 

data control block area to be freed. Reg? loaded from 

register RBLOCK which contains the addres lie . ^ to be 

freed. Then an 0/S FREEMAIN macro instruct. issued. 

Control then falls through to location RETURN where a standard 
load multiple of the user’s registers from location FBSAVE occurs, 
and a branch register return through register RR. At location 
DISASTER, register RP1 is loaded with a value of 28 to indicate 
entry from TMSCLOSE, and register RD is loaded with a V-type 
address constant of the entry point of TMSPURGE . A BR instruction 
is issued specifying register RC . 

Location TMSPCLOS is an alternate entry point to TMSCLOSE. This 
is an entry from TMSPURGE. On entry, register RP1 points to the 
chain element word rather than to the DCB. At location TMSPCLOS, 
the registers are stored into location FBSAVE. Register 15 is 
used for temporary addressability of location TMSPCLOS which enables 
an address constant specifying the entry point TMSCLOSE to be 
loaded into register RP . This provides permanent addressability 
for the program. Register RW0RK1 is then cleared. The negative 
offset from the chainword is then inserted into register RW0RK1. 

From this the address of the DCB may be found easily, and control 
is passed to location TESTDCB2. 
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4 . 4 TMSCNSL Module 



The TMSCNSL module has two entry points . The principal entry 
point, TMSCNSL, is entered from the TMSWAIT module when the console 
DCB indicates that a message has been received from the computer 
operator. The message test which has been enclosed between apostrophes 
in the operator* s response via the REPLY command is found in the 
internal buffer named RPLAREA. To test for the content of the message, 
a simple series of CLC instructions is used to compare the contents 
of the reply buffer t;^ see if it matches a particular key word. , 

If the first word of the response does not match any of the valid 
command words, control falls through to the routine labeled 'WHAT , 
which issues the message 

TMS101I COMMAND NOT RECOGNIZED. IGNORED. 

and then falls through to that portion of code headed by the label 
TMSREADY . 

If the response from the operator matches the key word "DUMP," 
a user ABEND with a code of 300 is executed in order to obtain a 
core dump and terminate operation of the monitor. 

The remainder of the module consists of code to condition the 
monitor system for the next response from the computer operator. 

This code is headed by the label TMSREADY, which is also the secondary 
entry point to this module . The code zeroes out the first byte of 
the console DCB area RPLECB and sets the response buffer RPLAREA to 
all blanks . The WTOR macro instruction is then invoked to write the 
message 

TMS100I READY 



on the console typewriter and direct OS to place the operator* s 
response into the buffer labeled RPLAREA. The final operation 
is to place the address of RPLECB into the first position of the wait 
list. This is done every time, even though it is necessary that 
this be done only on the first call of TMSREADY from TMSBEGIN in 
order to complete the system initialization. The only exit from 
this module is direct branch to the direct wait entry point TMSDWAIT 
in the TMSWAIT module . 

4.5 TMSCSIO Module 

The TMSCSIO module has four entry points: TMSCSIO, TMSWRDEQ, 

TMSRDRST , TMSCSIOR. The main entry point to the routine is TMSCSIO. 
The entry point begins with a standard store multiple into the user's 
save area, locating the function block, moving the stored registers 
to location FBSAVE , and establishing addressability to the program. 

At this entry point also the flags are set to indicate a normal 
exit. Addressability to the communication region is provided by 
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loading register RCR from location FBCR. Loading register RDECB 
from location FBDECB in the function block provides addressability 
to the data event control block. Loading register RLOB from location 
DECDCBAD in the data event control block provides addressability 
to the data control block. The function block entry flag is then 
set to indicate entry into TMSCSIO. After the entry, the next task 
is to find whether a buffer is attached to this function block by 
checking location FBBUFPTR for the presence of zeroes. If there 
is no buffer attached to this function block, a branch is taken to 
location I0ENTRY4. If there is, register RBUF is loaded with the 
address in location FBBUFPTR. Location FBBUFPTR is then cleared 
to zero, and the buffer is indicated to be the last by setting a 
flag (BUFFLAST). Register RPTR is loaded with the address in 
register RBUF offset +4 to point to the buffer itself rather than to 
the buffer control block. The length of the last message sent or 
received is loaded into register RPTR, and this length plus k 
(if it’s a shared line) is used to clear this buffer to blanks. The 
clearing operation takes place in the loop at locations I0ENTRY1 
through I0ENTRY3. At location I OENTRY 4 the task is to test whether 
the request is a read or write operation. This is done by testing 
location FBRWOP for the presence of a flag Indicating the write 
operation (FBRWRITE). If this flag is present, a branch is taken 
to location WRITE. If it is not, the read operation is resumed 
and a branch is taken to location READ. 

At location WRITE the return address from the write queuing 
subroutine is set into register RR, and location DECUFLGS is 
tested for a bit indicating that writing is in progress (DECUFWIP) . 

If writing is in progress , a branch is taken to location WRQUEUE to 
place this function block on the writing queue. If writing is not 
in progress, location DECUFLGS is tested for the presence of a bit 
indicating read polling in progress (DECUFRIP). If read polling 
is no 4 - progress, a branch is taken to location WRITE8. If 
pol ing xn progress, it must be stopped for the other terminals 
on the aae line so that this message may be sent. Register RR is 
loaded with the address WRITEO to indicate a different return from 
the write queuing subroutine, and a branch is taken to the write 
queuing subroutine at location WRQUEUE. 

At location WRQUEUE the queuing flags in the communication re- 
gions at location CRQFLGS are tested to see if the queue is empty 
(CRQEND). If it is not empty, a branch is taken to location QUEUE1. 
If it is empty, the address of the current function black is stored 
at location CR QUEUE . Location CRQFLAGS is set with a bit indicating 
that there is a function block queued for the write operation, and 
a branch is taken to location QUEUE4. If the queue was not empty at 
location QUEUE 1 , location CRQFLAGS is set with a bit indicating a 
function block queued for write ( CRQWRITE ) , and the affiress of the 
first queued function block is loaded from location CRQUEUE irh > 
register RWOn . _. At location QUEUE2 a loop is executed to find the 
end of the quruie . When the end of the queue is found, a branch 





is taken to location QUEUE 3 . At location QUEUE3 the end-of-queue 
flag for the function "block already queued is turned off- The queuing 
flags of the former FB are merged with the address of the new last 
entry and stored in the pointer- The flags indicating end-of-queue 
and a function block queued for write (FBQEND and FBQWRITE, respec- 
tively) are moved into location FBQFLAGS. The waiting-to-write 
count at location DECWWCNT is incremented by one, the waiting-to- 
write bit (DECUFWTW) is set on in location DECUFLGS, and a branch 
is taken to the return address that was previously loaded in register 
RR. If writing was already in progress, this location is TMSDWAIT. 

If read polling was in progress, this location is WRITEO . 

At location WRITEO, the polling reset flag (DECUFPRS) is turned 
on in location DECUFLGS. The address of the data event control 
block is loaded into parameter register 1, and a RESETPL macro 
instruction is issued to stop polling on the line. When control 
is returned from this macro, register RC is tested for a return 
code of 0 to indicate a successful polling halt. If the polling 
halt was not successful, a branch is taken to location ABEND. 

Otherwise, a branch is taken to location TMSDWAIT. If read polling 
was not in progress at the entry to this routine, a branch is taken 
to location WRITE8 where the terminal list entry for this console 
is loaded by obtaining the address of the terminal list from locatinn 
DECTLIST, placing this address into register RW0RK1 , and adding the 
terminal list offset for this function block from location FBTLOFF 
to the address in register RW0RK1 . The address in register RW0RK1 _xs 
now the address of the terminal list entry for this console. Using 
this address, the skip bit for this entry is turned off, and location 
FBRWOP is tested to see if the length for the message is already 
in register RPO . If it is, a branch is taken to location WRITE21. 

If it is not in register 0 , it is obtained from the start of the 
text and put into register RLNTH, and a branch is taken to the 
common coding at location WRITE22. At location WRITE21, register 
RPTR is loaded with the message address from parameter register 1, 
and register RLNTH is loaded with the length from parameter register ©. 

At location WRITE22 the process is to locate an output buffer. 

To do this, register RCTR is cleared to 0. The address of the buffer 
control block is put into register RBUF from location DCBBUFCB , 
and at location WRITE1 a loop is executed to chain through the buffer 
chain to find a buffer that is free. If no buffer is free, a brand!., 
is taken to location ABEND with a value of Ul at location CRABCODE- 
If a buffer is available, control falls through to location WRITE2 
where flags are set in the buffer control block for that buffer to* 
reserve the buffer. These flags indicate (l) buffer in use and 
(2) bufifgr waiting for output (BUFFINUS and BUFFWRTG, respectively) „ 
Register RBUF is shifted by four bytes to point to the start of 
the buf Itself rather than to- the control block. Location DECTTEET 
is tested o see whether the terminal is a typewriter or not. IT 
it is net typewriter, a branch ir taken to location WRITE 3 - IT ht 

is a type\ ~,er, location FBRWOP is tested to see if carriage returrr 
before te ... v as specified (FBRWCEBW , If not, a branch is taken tr 
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location WRITE3- If it was specified, the length of the last mes- 
sage is loaded into register RW0RK2, register RW0RK1 is cleared, and 
a halfword of zeroes is stored into location FBLMLNTH, which is the 
last line length. The value currently in register RW0RK2 is divided 
hy 10 to find the inches of carriage travel. The prefix length is 
added to the value in register RW0RK2 to find the total prefix length. 
Register RWORKL is loaded with a buffer address from register RBUF . 

The length value in register RW0RK2 is temporarily decremented hy 1, 
and this value is used to move a carriage return prefix into the 
buffer by an execute instruction specifying a move instruction at 
location MOVECR , The value in register RW0RK2 is reincremented by 
1 and this value added to the cumulative length in register RCTR. 

The text of the message is to be moved into the buffer at location 
WRITE 3 by first testing register RLNTH for the presence of a aero 
length. If the length of the text is zero, a branch is taken to 
location WRITE4 . Register RLNTH is then tested for a maximum 
length value. If it is over this maximum length, a branch is 
taken to location PURGE1 . The address of the buffer is then loaded 
into register RW0RK1 , and the length of the existing text from 
register RCTR is added to it. Also, the length value in register 
RLNTH of the existing message is added to the cumulative length 
counter register RCTR. The length of the outoging message is 
stored into location FBLMLNTH. 

At location WRITE30 the length value in register RLNTH is 
used in a move loop to move the total message into the output buffer. 
When the message has been moved, control falls through to location 
WRITE4 where, if the terminal is a typewriter and a carriage return 
after text was specified, the same code that was issued for car- 
riage return before text is executed. If the terminal is not a 
typewriter, or carriage return after text was not specified, a 
branch is taken to location WRITE? where the type of terminal is 
tested again to see if the terminal is a display. If it is not, 
a branch is taken to location WRITE5A. If it is a terminal, the 
buffer address in register RBUF is loaded into register RW0RK1 
and the length of the existing text in register RCTR is added to 
It. This address is one beyond the end of the message, and if the 
-terminal is a display, an end of text character is placed at that 
position, and the message length bumped by 1. At location 
WRITE5A, the cumulative length in register RCTR is put into register 
RLNTH, and the final buffer address is put into location RPTR. The 
■translation table address is loaded into register RW0RK1, and at 
location WRITES and WRITE7 a translate loop is executed to trans- 
late the outgoing message. The write-in-progress flag is then 
burned on at location DECUFLGS (DECUFWIP). The buffer length from 
register RLNTH is stored in the data event control block at loca- 
ruon DECLNGTH . The address of the buffer is stored into location 
PZ11REA. The polling address from location DECTLIST is loaded 
int register RW0RK1 , and the offset for this function block from 
loc-4?rion FBTLOFF is added to it. This address, pointing to the 
terrain al list entry for this function block, is stored at location 
IETHLJTRY. The relative line number for this terminal is moved 
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from location FBRLN to location DECRLN , and if the terminal is 
a display, a branch is taken to location WRITE9 - Otherwise, 
the type of operation in the data event control block is set to 
indicate a write initial with reset (DECWTIR) for a typewriter, 
and then the CRT display code is skipped by branching to location 
WRITE11. 

At location WRITE9 the operation type at location FBRWOP is 
tested to see if pre-erase was specified. If it was, a branch 
is taken to location WRITE10- Otherwise, the type of operation 
at location DECTYPE+1 is set to indicate a write initial with 
reset (DECWTIR), and a branch is taken to location WRITE11. If 
pre-erase was specified at location WRITE10 , the operation type 
at location DECTYPE+1 is set to indicate a write erase with reset 
(DECWTSR), and control falls through to location WRITE11. At 
location WRITE11 the data event control block is cleared to zero, 
and the write to the terminals is issued by issuing an 0/S WRITE 
macro instruction. After control is returned from this macro 
instruction, register RC is tested for a return code of 0 to 
indicate a successful start of write. If it was not, a branch 
is taken to location ABEND with a value of h2 at location CRABCODE. 

If the start of write was successful, a branch is taken to the 
exit routine at location RETURN. 

If the indicated operation at location IOENTRYU was a read 
operation, a branch is taken to location READ. At location READ 
register RW0RK1 is loaded with the address of the terminal list 
obtained from location DECTLIST in the data event control block. 

To this value is added the terminal offset found at location 

FBTLOFF. The skip bit at the resultant location is turned off, 

the type field of the data event control block ( DE CTTYPE ) is 

tested for the presence of a bit indicating several terminals on 

the line, and a branch is taken to location READO . If there are several 

terminals on this line, the active polling count at location 

DECAPCNT is incremented by 1. 

The data event control block flags at location DEBUFLG-S are 
tested for bits indicating either a read in progress or polling 
interrupt (DECUFRIP and DECUFPIN , respectively). If p olli ng is 
or was in progress, a branch is taken to location RETURN to return 
to rhe caller, as nothing more needs to be done,. If polling was 
not in progress , it must be initiated, an! control falls, through 
to location READO to locate an input buffer.. The address of the 
buffer control block is obt ain ed from the :!ata control [block, and 
the first buffer is tested for the presence of a flag .Indicating 
buffer In use (BUFFINUS). If the buffer Is not in use. a branch 
is taken to location ZREAD2 . If it is in use, a loop la executed to 
chain down through the buffers to find a free one. Xf one can not 
be found, a branch is taken to location ABEND with a value of ^-3 
at location CRABCODE for the abnormal end code in the communication 
region . 
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At location READ2 the flags on the newly-located buffer are 
set to indicate buffer in use and buffer waiting for input 
(BUFFINUS and BUFFWTIN , respectively.) Register RBUF is 
incremented by 4 to point to the start of the buffer. Next, the 
data event control block flags are tested for the presence of a 
bit indicating write in progress (DECUFWIP). If it is in progress, 
a branch is taken to location READ4 to put the read parameters 
into a save area. If it is not in progress, the operation code 
of a write initial (DECRTI) is moved into the type field of the 
event control block to set the operation code for this operation. 

At location READ21 the length field is set into the data event 
control block from location DCBBUFL. The buffer address now in 
register RBUF is stored into location DECAREA. The terminal list 
address is moved from location DECTLIST to location DECENTRY. The 
relative line number for this terminal is also moved from the 
function block at location FBRLN to the data event control block 
at location DECRLN. The data event control block flags are set 
to indicate read in progress. The data event control block is 
cleared, and an 0/S READ macro instruction is issued. After the 
macro instruction is issued, polling is in progress, and a branch 
is taken to location RETURN. 

If, at location READ2, the line is found not to be free, a 
branch is taken to location READU to save the current parameter 
set for a later restart of the read operation. At location 
READU location DECRSAVE+10 is tested for the presence of flags 
indicating that a restart parameter set already exists . If it 
does, there is a fatal error, and a branch is taken to location 
ABEND with a value of 45 at location CRABCODE. Otherwise, the 
first byte of the operation code, a hexadecimal zero, is moved 
to location DECRSAVE in the restart parameter save area. The 
second byte of the operation code, a read initial (DECRTI) is 
moved to location DECRSAVE+1. Likewise, the buffer len gia from 
DCBBUFL, the buffer address in register RBUF, the terminal polling 
list address from location DECTLIST+1, and the relative line 
number from location FBRLN are moved Into respectively higher 
locations in the parameter save area.. :The data event control flags 
are set to indicate polling interrupted (DECUFPIN) and a branch 
taken to location RETURN to exit to the caller. 

At location RETURN the program flags are tested for a bit 
indicating a direct entry to the wait routine is to be taken. 

If it is there, a branch is taken to location TMSDWAIT for a 
special exit. Otherwise, the function block entry flags are 
cleared, the user’s registers from location FBSAVE are restored, 
and a branch taken back to the user routine . At location TMSDWAIT 
the register RC is loaded with a V-^ype address constant specifying 
the location TMSDWAIT, and a branch :is taken using register RC . 

Location PURGE1 loads parameter register 1 with a value of 
5 6 and branches to location PURGE. Location PURGE loads register 
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RC with a V-type address constant for TMSPURGE and branches to that 
location. Location ABEND issues an 0/S ABEND macro instruction 
specifying a user completion code of 777 with a dump to be taken. 

Location TMSWRDEQ is another entry point to the TMSCSIO 
routine entered from the TMSWAIT routine when the TMSWAIT routine 
finds that more than one terminal has issued a write request at 
the same time. The entry is directly from the routine TMSWAIT 
and serves a function of dequeuing the already enqueued write 
operation for the second terminal. This entry point provides 
temporary addressability by using the address in register RC . 

It also provides permanent addressability by loading the base 
register. Register KB, with the value of an address constant 
specifying the location TMSCSIO. The program flags are reset 
for a normal exit; addressability to the data event control 
block, the data control block, and pointers to the message address 
and the message length are loaded. The waiting-to-write count 
is decremented by 1, and if it is not 0, a branch is taken to 
location WRITE to issue the write for this terminal. If the 
waiting to write count (DECWWCNT) was zero, the data event control 
block flags are reset to indicate no more functions waiting to 
write, and a branch is then taken to location WRITE. 

TMSRDRST is another entry point directly from the routine 
TMSWAIT. It is similar in function to the entry point TMSWRDEQ 
because it is used when the routine TMSWAIT finds that when one 
function block had issued the read operation, the write was 
already in progress, and the parameters must h*r~e been saved. 

When the write operation has finished, the rcuxine TMSWAIT usgl 
this entry point to stall up the read that was queued at a previous 
time. It provides temporary program addressability by using the 
address in register RC , loads the base register RB with an address 
constant specifying the address TMSCSIO,, loads the pointer to both 
the data event control block and the daita control block into 
registers RDECB and RDCB , reside ctively , and branches to location 
BEADO to set up a new read. 

Location TMSCSIOR is another entry point used by TMSWAIT 
when the end-of-transmission. routines indicate an I/O error by 
setting a flag in the function block (FBXMTERR). This routine 
also establishes temporary and permanent addressability and 
loads the pointers to both the data event control block and the 
data control block into registers RDECB and RDCB, respectively. 

It then clears the function block event control block to prevent 
dispatch the next time TMSWAIT is entered, and then tests to find 
which operation resulted in a permanent I/O error. If it was a 
write operation, a branch is taken directly to location WRITE11 
to reissue the write. At this point the data event control block 
still contains the information it had when the write was issued. 

If the operation was a read rather than a write, the sense byte 
at location DECSENSO is tested for indications that the error was 
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timeout, lost data, or intervention required- If it vas any of 
these, special processing is needed, so a branch is taken to 
location CSI0ERR1. If it was not one of these, a read retry 
operation code is moved into location DECTYPE+1. A buffer address 
is loaded into register RBUE from location DECAREA, and a branch 
is taken to location READ21 to reinitialize the read operation 
for a read retry. 

At location CSI0ERR1 the type field of the data event control 
block is tested for a bit indicating multiple terminals on this 
line. If there are not multiple terminals, a branch is taken 
to location CSI0ERR2 to skip the following code- If there are 
multiple terminals, the active polling count is loaded into 
register RW0RK1, decremented by 1, and restored. The address 
in pointer is updated to correspond to the terminal list entry 
that was last being polled, and a write positive acknowledge 
operation is issued to the terminal. The write positive acknowl- 
edge is tested lor successful completion, and if it was not 
successful, the operation is retried 10 times. If it was 
successful, a branch is taken to location CSI0ER12, 

At location CSI0ER12 an 0/S WAIT macro instruction is issued 
to wait for the completion of this write positive acknowledge. 

Rather than exiting to the routine TMSWAIT, a wait is issued here 
cause the monit^ system must remain in control at this time, 
u jntrol then fali ough to location CSI0ERR2 where the read-in- 

pro ess and write-in-progress are turned off. A cumulative 
length counter is cleared and the buffer address obtained from 
location DECAREA. The buffer i.s released, and message pointers 
are set up in register RLNTH and RPTR. The read and write operation 
flags at location FBRWOP are set to indicate a write operation 
with pre-erase, carriage return before write, and carriage return 
after write (FBRWRITE, FBRWPE, FBRWCRBW , and FBRWCRAW) . A branch 
is then taken to location WRITE2. dt.o issue a system message to the 
screen in question, indicating £ permanent uncorrect able I/O error 
and requesting the reissuance of' trke last message. 
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4.6 TMSGMFM Module 



The function of TMSGMFM is to obtain or free main, storage 
upon request of a user program. The routine will either obtain 
a block of storage and append it to the storage chain in the 
Function Block CFBBLKCHN), or it Trill free a specified block 
of storage previously obtained by a TMSGETM and update the 
storage chain appropriately. 

Upon entry * TMSGMFM saves the calling program* s registers 
in a temporary save area. Then immediately upon location of 
the Function Block, the registers are moved to the FBSAVE area. 
Next, the GMFM entry flag is set in the FB, and register 1 
(RPl) is tested for a zero condition. If register 1 contains 
zero, the intended operation is a GETMAIN, and the requested 
size is in register 0 . If register 1 is non-zero, the intended 
operation is a FREEMAIN, and register 1 contains the address 
of the area to be freed. 

The TMSGETM routine first checks to see if return with a 
condition code is requested. If yes, a special return flag is 
set on. The routine then bumps the requested GETMAIN size by 8 
bytes to cover the storage chain and Issues a standard condition- 
al GETMAIN. If the GETMAIN was successful, the size of the 
block is stored in the second word of the area, and the previous 
last entry on the storage chain (FBBLKCHN) is stored in the 
first word of the area. The address of the newly obtained 
storage block is then loaded into FBBLKCHN. The address of the 
first byte available to the user (i.e., the first byte following 
the 8 byte storage chain) is loaded into register 1, and control 
is returned to the user. 

In returning to the user who obtained the requested storage, 
the GMFM entry flag is set off, the registers are restored from 
the FBSAVE area, and control is returned. If core was not 
available, however, two options are possible. If return is 
requested, register 15 is loaded with the return code of 4, and 
control Is returned as normal. If return is not requested, 
control is passed to TMSPURGE with a return code of 8, which 
'will purge the user and indicate insufficient main storage left 
to satisfy a TMSGETM request. 

Upon entry , TMSFREEM decrements the address supplied by the 
user by 8 bytes . The storage chain is then searched for the 
resulting address. When the block is found, it is freed, and 
the storage chain is compressed, deleting the freed block. If 
the address is not found in the storage chain, control is passed 
to TMSPURGE with a return code of 12, which will purge the 
user and indicate that the TMSFREEM request does not specify a 
legitimate address. Otherwise, return is returned as In TMSGETM. 
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k. 7 TMSGTSLE Module 



TMSGTSLE Is a service module of TMS designed to simulate 0/S 
QISAM while saving approximately 7K “bytes of storage. Like 
other 0/S access method modules, it is loaded, “by the OPEN routines 
(in this case, the TMS OPEN routine) and, therefore, is passed 
dynamically in and out of storage depending on usage by a user 
program. Like other 0/S access method modules, it is coded in a 
re-enterable fashion. The program is invoked by the use of 
TMS GET , TMSSETL, or TMSESETL macro instruction. 

At entry to the program, register 1 will contain the DCB 
address and a flag in the top byte to indicate GET, SETL , or 
ESETL. Register 0 will contain data which vary depending on the 
option selected. 

The TMSGTSLE module has one entry point named TMSGTSLE. The 
module begins with a store nrultiple of register .lU through 12 in 
the user's save area, and then tests register 1 for a minus value 
indicating SETL function. If register 1 is minus, a branch is 
taken to location SETLROUT. 

At SETLROUT the key address and key length specified for the 
TMSSETL macro are transferred to register 2, and the DCB address 
is transferred to register 3- A TM3GETM macro instruction is 
then issued to obtain an area of core equal in size to the block- 
size of the file plus four hundred. These four hundred bytes 
will contain a save area and work space for other routines. When 
the save area is created, it is linked via standard linkages to 
the user’s save area, the address placed into register 13, the 
FB address placed into the first word of the save area, and 
register 0 and 1 restored from 2 and 3, respectively. The 
registers 0 and 1 are then stored at location REG0 and REG1 in the 
work area, the READ macro instructions parameters moved to the 
work area, and a flag set to indicate no reads as yet. A condition 
code of hexadecimal 80 is stored at location ABSRDIND to be used 
later in an execute of a branch on condition instruction. This 
is equivalent to a condition of equal. Location REG0 + 1 is then 
tested for zero. A zero here indicates that option B of TMSSETL 
was requested, and location ABSRDIND is changed to indicate 
unconditional branch (hex 1 FO r ) . Next, the logical record length 
and blocksize are loaded into registers 2 and 5, respectively, and 
the blocking factor is computed by a divide. The result is stored 
at location BLKFACT. Then the key length, blocksize, and buffer 
address are loaded into registers 5,3, and 6, respectively. If 
option B was indicated, the key area is zeroed, the address is 
loaded into register 9, and a branch is taken to location 21. If 
option B is not selected, the address of the key (stored at REG0) 
is loaded into register 11 and the key length (decremented by l) 
is used to move the key to the key area at location KEYBUMP. 

Control then falls through to location LI. 



At- location LI, the DCB address is located from REGl, and 
the address of the work area (called LOCAL) is stored in a TMS— 
supplied fullword at location. 2U0 of the beginning of the DCB. 

At location RETURN , the parameter registers are stored in the TOrk 
area save area, register 13 is restored, and control then falls 
through location OUT to a TMSRETURN macro instruction. 

If, at entry to TMSGETSLE, register 1 is not minus, the 
address of the work area is obtained by loading register 10 from 
the address contained in register 1 plus 2U0. Local addressability 
of the work area (LOCAL) is established by using this address. The 
top byte of register 1 is then tested for the presence of a 
hexadecimal ^0 . If it is not present, a branch is taken to the 
ESETL routine at location ESETLROU. If present, GET is indicated 
and a branch is taken to location READOUT. 

At location ESETLROU, the save area chain is changed to 
Indicate the last save area, the work area is freed by issuing 
a TMSFRERM macro instruction, and a branch is taken to location 
OUT for a return to the user. 

At location READOUT the parameter registers are loaded from 
the work area save area where they were stored at the end of the 
SETL routine. The read indicator at location RDIND is tested for 
a hex '01* to indicate if a read has been issued or if one needs 
to be. If location RDIND equals hex f 01 f , a branch is taken to 
the routine to locate the next record at location RECFND. If 
not, a READ macro instruction is Issued and tested for completion 
with a WAIT macro instruction. A normal completion is tested by 
masking appropriate bits in the BECM. If completion is normal, 
control is passed to RECFND. If not, control passes to IDERRORS 
which loads a completion *code, and the address of a message and 
returns to the laser. 

At location RECFND. the key length, or partial key length, is 
obtained from the work area and used to compare the key to the 
first key in the block read-in. The code at location ABSRDIND 
is then used as a branch code. If the B option is specified in 
the TMSSETL macro, ABSRDIND always indicates a branch to location 
MATCH. If option K or KC is selected, ABSRDIND indicates branch 
only on equal condition. If the key is not the same, register 4, 
containing the number of records per block, is decremented by one 
and tested for zero. A zero here indicates record not found and 
an error condition code and message are returned to the user. If 
register 4 is not zero, the record length is added to the current 
record pointer to point to the next record, and a branch is taken 
to location EXE to re-enter the loop to locate the proper record. 

If control is passed to location MATCH, then the proper record 
has been found. Thus , the key no longer matters and so is set. to 
hexadecimal F’s. Likewise, ABSRDIND is set to T F0 T to indicate 
unconditional branch. Control will now pass directly to MATCH upon 
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entry if GET is specified* The record being pointed to is then 
tested for MATCK against a. key of h_e.x F*s to see if this is the 
end— of-file* If it is, the address of the users EODAD routine 
is loaded and a return made to that point. If it does not indicate 
end-of-file, register 4 Is tested to see if it Is the last record 
in the buffer* If not, register 1 Is loaded from register 6 to 
give the record address to the user, register 6 incremented to 
point to the next record for the next Issuance of the TMSGET macro 
instruction, and the count of records remaining in register 4 
decremented by one. At CLOUT register 1 is spaced by 1 6 to 
account for the block header, registers 0 and 1 stored at the 
appropriate place in the save area, and control passed to RETURN 
to return to the user. 

If the count of remaining records indicates the next record 
in the buffer is the last, control is passed to location LASTREC. 
Here, location RDIND is set to zeros to indicate that a read will 
be needed next time, and the key is obtained for the READ by 
picking up the last key in the present block and adding one to it* 

The number of records remaining is reset to the blocking factor, 
the pointer to the current record loaded, and the address in 
register 6 set to the beginning of the buffer. A branch is then 
taken to location CLOUT to store the registers and return to the 
user . 

4.8 TMSHSKP Module 

The TMSHSKP module begins with a standard 0/S register save 
sequence. A save area within the housekeep routine is linked to 
the save area provided by the 0/S monitor. The routine then issues 
the message: 

TMSOOOI ILR TERMINAL MONITOR SYSTEM INITIALIZING 
to the computer operator. 

The next major operation is the loading of a predetermined 
subset of access method modules into main storage where they will 
reside for the duration of TMS operation. The list of modules to 
be loaded is given as a BLDL list labeled LOADMODS. The first 
half of the list is a binary count of the number of entries in 
the list. This count must be altered if the number of entries in 
the list is changed. The standard list of I/O modules is given as 
Appendix 4 . The load process is initiated by issuing a BLDL 
specifying the load list as parameter. A completion code of 4 from 
the BLDL macro indicates that one or more modules are missing. The 
routine beginning at label MISSING loop c .^Ji the BLDL list , 

testing for a zero record field- which . n a missing module. 

For each missing module encountered, the mes : ge: 

TMS 001 I TMS INITIALIZING ERROR. UNABLE TO LOCATE MODULE xxxxxxxx 
is issued to the computer operator (xxxxxxxx represents the name of 
the missing module). When this loop is complete, the program is ab- 
normally terminated with a user code of 001. A return code of 8 from 
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FIG. U 

STRUCTURE OF TMSGTSLE WORKAREA (l PER QISAM DCB ) 
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the BLDL macro indicates an I/O error occurred while attempting 
to read the module directory. Control is passed to the code 
Labeled IOERROR which, writes the message: 

IXG0G2I tms utitialtzihg ERROR. I/O error while reading module 

!. 1 ^ELTORY 

t; : he computer operator. The program is then abnormally terminates 
v ' tii. a user code of 002. A completion code of 0 from the BLDL macro 
iicates the successful location of all routines. Cozdrrol passes 
> the code at label LOAD which first loops through the ELDL lisib 
L then issues a LOAD DE call for every entry in the list:. 

The next major operation is to establish the ccnmmmi ;&ition 
'^gion (CR). For the purposes of this code* the length ci the 
muni cation region to be obtained is represented by e. value 
CRLENGTH, defined in the CR dsect. An R-type GETMIL m&cro is 
i j: ued to obtain the core. The core is cleared with a sin. Le XC 
.ruction (which implies a CR length of 256 bytes or legteO. The 
iress of this newly obtained area is placed in RCR* a ihnures sa- 
nity is established using the CR dsect. Finally* the ema^-cpf- 
: eue flag is turned on in CRQFLAGS. 

In addition to data sets for each communication line IMS also 
responsible for providing three other data sets: the "T^tem 

arary * the snap* and the system log data sets. The tousiskeep 
- utine contains the skeleton DCB’s for these cmta sets whi^ch are 
^Ueled LIBDCB* SNPDCB * and LOGDCB * respectively . Tbs combined 
f-ngth of the three DCB skeletons is represented by the value of 
.CZ3LGTHS * which is used to provide the length speci first ion for 
hi R-type GETMAIN macro instruction. If the core is obtained* a 
op is employed to move the skeletons into upper core a. double- 
word at a time. Space is provided at label OPENLIST for pointers 
\'r- the three DCB’s mentioned above plus up to 100 pointers to line 
-3’s. The pointers to the library, snap* and log D.CB’is are 
v \jv dated within this open list and also placed in their proper 
positions in the CR. Register RPTR is initialized to point to the 
torrent last entry of the open list and will be updated as line DCB 
addresses are added to it. 

The most important operation of the housekeep r.ourtne is to 
set up terminal control blocks and buffers in main storage for 
use by the IMS exe cut i on-time routines. Both the skeletons for 
these terminal control blocks and certain parameters are supplied 
by the TMSBLOCK module. The combined length of all terminal control 
block skeletons is obtained via the entry point TMSBLGTEL As 
before* this length is used in an R-type GETMAIN macro Instruction. 
Once the core Is obtained* the start of the combined terminal 
block skeletons is located via entry point TMSBLOCK* and the 
’“orminal block skeletons are. moved Into upper main sto r age a 
ubleword at a time-. The rest of the processing -consists of 
.^oceeding through the various chains de. ned Irr tie terminal control 
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block skeletons and updating all addresses to point to the new 
copy of terminal conrrol block skelexons in upper main, storage. 

This means that to every address must be added an increment 
representing the difference between the copy of the skeletons 
in upper core and the original -Location of the skeletons • Ibis 
increment Is computed and placed, in the register RIMUR. The 
incrementing process begins by finding the original address of 
the last FB in the chain via the entry point TMSLSTFB in module 
TMSBLOCK. This address Is incremented and stored in the CRFBCHN 
vord In the communication region. Since this now gives the 
address of a new FB , the various pointers within the EB are 
* ncremiented. As each new FB is encountered, a halfword in the 
C.R* CRWLX is _ mrementedL to accumulate a count of the number of 
T3 1 s in the This will be used later in setting up the 

wait list. Tfce rrocessizng of all FB ? s is assured by following 
the chain of ~ r B’ v -=s. down to its conclusion. Whenever we process the 
first FB for . 'articular communication line, control is passed to 
the code, star- mg at label TBLGCK5 > which processes the newly 
located DECB. This cede also increments register BLCT by four to 
increment the count of communi cation lines in the system. From 
here control ^t-iss-es “to code for processing the newly located DCB 
and appending che DCB address to the vector of DCB addresses in 
OPENLIST. Each address is inserted by turning off the end-of-list 
bit in the preceding fullword, inserting the address in the 
current fullvord, and turning on the end-of-Ust bit in the same 
fullvord. The other major operation is to move the DCBBUFCB 
pointer contents into the associated communicating line DECB and 
reset DCBBUFCB to x’OOOOOl 1 . This is done to prevent the BTAM 
dynamic buffering module IGG019MS, which is never needed, from 
being loaded by the OPEN routine. Following DCB processing, control 
falls through to process those buffers associated with the DCB by 
updating the buffer chaining addresses. Control is then returned 
to the middle of FB processing at location TBL0CK2. Processing 
of FB f s continues as described above until the list FB is processed. 
Control is then passed to location WLIST. 

The next major job to be done is to prepare the initial 
configuration of the wait list and to load the "phantom job". 

Because they are; highly interdependent, these tasks are performed 
together. . First, the length of the list must be determined. The 
accumulated count of FB's is obtained from CRWLX. This count is 
incremented by 2: one for the console wait list entry and one for 

the queuing/wait list entry. The resulting count is multiplied by 
four to give a result in bytes , which is then incremented by the 
contents of register RLCT , representing the number of bytes needed 
for pointers to the communication line event control blocks. The 
final totsl is stored in CRWLX to serve as the wait list offset. 

This total is then multiplied by two to obtain the overall length 
of the wa: " list and used in an R-type GETMAIN macro instruction. 

A " -or .I- p erformed to zero out the core so obtained a doubleword 
at taina . BLDL macro instruction Is issued to locate the 
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directory entry of the "phantom job" module TMSPJOB. In case of 
error curing ohe BLDL^ branches are taken back: to the code that 
loaded ifhe I/O access .method modules in order to report the error 
to the operator and abnormally terminate the program. If the BLDL 
is successful, s -LOAH 1 'DE macro instruction is issued to bring the 
"phantom job" in to co re. A loop is then performed to move the ILine 
event control cJLctk addresses into their section of the wait list 
and to s^t a fHeg in the corresponding wait list extension locations 
in order to shew that, they represent line event control blocks , 
not terminal event control blocks. This flag pattern consists of 
all one bits in the first byrte and all zero bits in the remaining 
three bytes of the feTiw or d - 



Hce last operation is to proceed through the entire chain of 
functi:cc;i blocks -setting arc various locations in the FBSAVE area and 
enterimg a pointer ten -earn FBECB in the wait list with the 
corresponding FB address in the wait list extension. The completion 
bit also is set 022 ire the FBECB to ready the DB for dispatching when 
execution of the sy-nenr begins . At the end of this loop, CRWLLAST 
will he pointing; to the last entry in the wait list, and the end- 
of-list bit will s Zs-r- be: set on for the last entry in the wait list. 
The effect of all this is to prepare all function blocks to begin 
execution with registers? 12 (RB), lU (RR), and 15 (RC) pointing 
to the start of the "phantom job", register 10 (RCR) pointing to 
the . zam mun i c at i qc region -and register 11 (RFB) pointing to the 
funr+ : .on block. This is the initial execution state for every 
terzu L?::al in the systeon. 

The next operation to be performed is the OPENing of all DCB's 
currently defined in the system, coupled with a certain amount 
of gg-st-OPEN processing:. The open parameter list labeled OPENLIST 
has been completely prepared by previous code. All that is 
ne:cas'sarry to open DCB r s in parallel is to issue the OPEN macro 
instruction, with this list as the parameter. Post-OPEN processing 
cons ists of a loop to make one more pass through the chain of 
all ,F3 f :s. For every TEB that is the first on the chain on its 
c omm jttx-.c at i on line., cade is entered to both move the buffer 
pointer from the HECJ3 to the DCBBUFCB pointer and clear the DECB for 
use by the system* This reverses the earlier action which prevented 
the BIAM dynamic buffering module from being loaded inadvertently 
at GEEjN time. The remainder of the process is executed only if 
the FB represents a terminal on a multi-drop line. In this case 
the BTAM operation "s:end ack" is initiated to send an EOT character 
down the .ling to initialize the remote devices (in the present 
case, the Senders; displays). If for any reason the attempt to 
issue the BTAM write operation is not successful, the program 
abnormally terminates with the user code of 003, which indicates 
further difficulty :i: the line. The program waits for a positive 

response from this operation before proceeding on to the next FB. 

The final operations are to inform the operator that the 
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terminal monitor system is beginning its normal operation andl to 
transfer control to the executor por^iL'on ci the system. The 
message : 

TMS003I ~LB TERMINAL MONITOR SYSTEM S2SRTSD 

is written on the console typewrite. The commusalccr? • _on reglizn. 
address is placed in register 1 ClRrl). The pointer , : the 'IMF. 
library D'C3 is placed in the XCTI parameter list, sxl the XJT1 
macro instruction is invoked. Tims exit from TMSHSX causes the 
TMSEXEC load module to overlay directly the houseke ep routine and 
begin execution. 

h . 9 TMSOIEU Module 



TME>??E3N is a module of TMS designed to construmr and open a 
user data control block -with only a knowlelge of the lata set 
name. Therefore , TMSOPEN differs from 0/S standards which require 
a DD name, the access method, and the MACE? paramet err- of tie DCB. 

The module begins with a standard store multiplier into the 
user’s supply SAVE area. The address of the user's ftmction block 
is obta ine d from the first word of his save area,, which provides 
addressability to his FB. The store registers are then copied 
from his save area into location FBSAVE , and the user ; s -uave 
area is thereby freed for use as the save area oi the TM30E3R 
routine. The entry point to the module is obtained from register 
RC , loaded into register RB , and used to provide addressability 
for the programmer. The address of the communication region is 
loaded imho register RCR from location TBC1EL and used to provide 
addressability for the communication. Register BP1 is loaded into 
register IEPARM and used to provide addressability for the- remote 
parameter His t . At this point, the task is to search for a 
catalog entry for the data set names specified Iby the user. The 
location 1DSNAME is cleared to blanks, and the address of the data 
set name is obtained from the parameter area, likewise, the 
length of the data set name is obtained from the parameter area. 

These two values are loaded into registers RPTP and register RCTR , 
respectively. If the specified access method is EXCP with appendages 
required, a special branch is taken to location CSEARCEX. At this 
point, the data set name and the data set length addresses are 
loaded from special addresses in the parameter area into the proper 
registers . 

Control then falls through ho location CSEARCHB , where the 
length of the data set name is teted for validity. If the length 
is zero or negative , a branch is taken to location ZOTSAETER^ Other- 
wise, the length is used in an exssmite instruction to mrye the 
data set name to the parameter area for the catalog search. The 
parameters specified by the users' are tested to see if the data 
set is qualified by a user name. If not, a branch is fea to 
location CSEAPCH1. If it is to he qualified, a period is moved 
into the first ■ .nation after the data set name, and the name 
currently in the user's function block is appended to the data 
set name. Control then passes to location CSEARCH2. At location 
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CL'TLARCHl t; :ie. par-asseter flags are -tested to see if une user wants 
tu qualify the harm set name by the teictioni block number. If 
ubt, cortrul is to locatic I3EARCH2. If ±t is to be 

qualified. the Tiaracruers 1 . EB 1 ar^ no ve d to the first positions 
after the rata set name. Then, f ^ terminal number from location 
TB‘ “ERMNO xn movtiid to the first petition following the characters 
? ZB 1 . Ccrs-rol them falls through tc location CSEAHCK2, 

At lo ratio: • GSSE201H2, a catalog search is done by issuing an 
D/S LOCATE macro, xrsrrruc t i on specifying a parameter list called 
BYEiAME. Tnre results of this macro imstrcction are tested upon 
resum by nrarcih htole. If the retorn code is zero, then a 
catalog emory h^s bean found so a br anch is taken to location 
CSZARCH3. Brancs are taken to lc^urions DISASTER or CMTSSING 
if the correct roioy? was not found* The entry was mt found, the 
final entry was not the data set or various order error 

ccoditions exist. At location C3E2RC TH'3 , a search is made to see 
that all ‘volumes fcr this data set iare mounted. The location 
TJ-ITPTH is tested to see if a pointer to- the task- 1/0 table 
already exists. If mot, this address is found tr the use of an 
0/13 EXTRACT .macro Instruction . Control then fall through to 
location CEEARCffl where the volume count is loaded from' the catalog 
entry at location "W02SEAREA- A pointers is loaded to point to the 
first volume entry, san another pointer is set to point to the 
first DD entry. IThess pointers are ihTR and RTIOT, respectively. 
Since, under the Terminal Monitor Sysoem, DD names 'ire names to 
correspond t:o the voIcEie they specify, DD name ILEO— will specify 
a volume lilO^. A match merely has to be done betvesa. the volume 
name specified in the: catalog and the DD name currently pointed 
to by register IHTI0T1 Once the volume serial number snatches the 
DD name , control is passed to locntf on CSEARCHT. Tf the volume 
serial number does not match the DD name , the register RTIOT is 
bumped to point to the next DD entry. A fnllword of fa in ar y zeros 
at the address currently pointed ta “by register RTIOT m.di cates 
that an entry does not exist. Tfoersffare , there is mu. HD card 
■given for _the volume requested. Aa "branch is then teen to 
location VMJSSITNG to indicate this volume is gam . If a DD 

entry exists,, ccontrndl is pas^iiao location CIBEARCIE6 i~o try 
again to malteh. tier volume serial numiber to trie DD name. 

At locaticsn C3EARCHT* after sa check to see that the volume 
is mounted prapreryy^ *a test ±s mdg„ through the us;e of an 0/S 
OBTAIN macro iz^Lrmcti cm T for the existence of a date set control 
block with the ' 1 rame* specified hy tree user. A hranrki is taken using 
the return code, -hi index to a branch table, to either location 

CSEARCE if the da ta , set control block: is found, or variously, to* 
locations DIS'ATTME or CMISSING, depending upon the sri’tr conditions. 
At location CSEARGh hrb-s pointer to the volume entrv in the catalog 
entry Is bvinved to point to the next volume entry - Agister RCT R. 
containing the number of volume entries, is dec remarked by one, 
and a branch is tshen to location CSEARCH5 to estai: _Lsh that this 
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volume is mounted . Once the volume count in register RCTR becomes 
zero, control pass es through to a section of code which will com- 
pute the required lengths cx the (data control lb lock based upon 
the access method rrequee sted. The first; test is to see if the access 
method! requested wms HXCP . This is done by testing location 
PMACEEF in the parameter area supplied by the user for the pre- 
sence of a he:: ;ade chsEsl 80 (P3XTE). If this bit is not present, a 
branch is taken tc location F0RMDC3X to test for the next access 
method. If in is yrress: nt , register RW0BK1 is loaded with a value of 
5 6 for the 52 byte- ftr the EXCP acmes s method data control block 
plus 1 bytes for the; data control block chainword required by the 
Terminal Monitor System . Register RmOBKX is cleared to zero, and 
location PMACPF is teamed to see if appendages have been requested 
for this access metricrn If not, a branch is taken to location 
F0RMDCB5 to obtain the core for the DCS- If appendages have been 
reqxested, a Irtlgth ci 20 is added to the value in register RW0RK1 , 
and a branch is - taker to location FORMDOB5 . 

At location T2v5ME j 131, location PDSORG is the remote parameter 
area is tested for *mhe presence of a hexadecimal 80 (PBIXIS) to 
indicate the request; for the index sequential access method. If 
this bit is not present, a branch is taken to location FGEMDCB2 
to test for the ne:tt access method. If the index sequential 
access method has been requested, register RW0RK1 is loaded with 
a value of 2hh for the 236 bytes required for the index sequential 
access method, plus 'U bytes for the chainword, plus b- bytes used 
by the Terminal Monitor System module TMSGrXSLE. Register RW0RK2 
is loaded with a value of l6 for the negative offset of the DCB. 

A branch is then taken to location F0RMDCB5 to obtain the core 
for this DCB . 

At location: FGEMDCB2, PBSORG is tested for the presence of a 
hexadecimal 20 ( P3TEDA)) indicating the direct access method. If 
this bit is net presemh, a br anch in taken to location F0RMDCB3. 

If the direct access method has been requested, register W0RK1 
is Loaded with a value of 92, register 35PT0KK2 is loaded with a 
value of _l6 , and a hsramch is taken isn iocstioii F0RMDCB5 . At 
Icrcathon ' T FQRMi:t.CB3 , HDK39Gr is tested for the presence of a hexa- 
decimal CEBITS*) indicating that the physical sequential access 
method has been re'tmesned . If this hit is not present, a branch 
is taken to location DISASTER , since dl siccess methods have now 
been tested. If this 'hit is present, register RW0RK1 is loaded 
with & value of 92, and register RW0EK2 i- cleared to zero. Con- 
trol then falls through to location FORTffiCB5 . 



location PORM0CB5 r€gi s >ter H?C is loaded from register 
RWORKlj aid then an 0/S 1ETMAIN maezre- instruction is issued 
specifying that the length of core to be obtained is now in regis- 
ter 0, The address, of the core obtained is to be placed into loca- 
tion CQEEADDR. Upon the return frc-rn this macro instruction, the 
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return code In register RC Is tested for a successful completion , 
and if register EC is not zero, a "branch is taken to location 
N0C0RE4 t(0 indicate core not available. Control passing to the 
next instruction implies successful completion, and register RDCB 
is loaded with the address at location COREADDR. Register RW0RK1 
is stored at location DCTELMHI is case the length of this data 
control block could he used in an emergency flush- Register 
RU0RK1 is incremented by 1 and used in an execute instruction to 
clear the obtained core tco zero. From location FBDCBCHN the 
pointer to the next data control block is moved into the chain 
element word pointed to by register RDCB. The negative offset in 
register KW0EK2 is placed at the top byte of the word pointed to 
by register RDCB- Register RDCB is then placed at location 
FBDCBCHN, and the chaining of this DCB with the other DCBs connect- 
ed to this function block is complete. Once the data control 
block offset has been subtracted from it ? register RDCB is used 
to provide addressability to the data control block through an 0/S 
DCBD macro instruction. 

At this point it is necessary to obtain the Job File Control 
Block (JFCB) for the volume or volumes upon which the data set 
resides, and 0/S GETMAIN macro instruction is issued specifying a 
length value of 464- This is to test whether enough core remains 
for the RDJFCB. Upon return from the GETMAIN, register RC is 
tested for zero, which indicates normal completion of the GETMAIH 
macro instruction. If register RC is not zero, the GETMAIN is 
not successfiH, and a branch is taken to location N0C0RE3. If the 
GETMAIN is successful,, a BREEMAIN macro .instruction is issued to 
free the core obtained py the GETMAIN- The Data Set Control 
Block for the first wnlinsie of the data set then is reobtained using 
an Q/S OBTAIN macro instruct i on . If this macro instruction is 
not successful, a branch is taken to location DISASTER. If it is 
successful 3 a dummy DD c^ame. is constructed at location DSVOLS first 
by clearing this location to blanks and then by moving in the 
first volume number from location VOLUME. Location WORKAREA is 
tested to see if there is more than one volume. If there is only 
one volume 3 a branch is taken to location FNDJFCB1 to find the job 
file control block. If there is more than one volume, location 
DSVOLS plus 4 is shifted over one byte so that the volume number 
of the next volume upon which this data set resides may be 
appended to this volume number (i.e., if the data set is resident 
on the volumes ILR03 and IDR'05 , the DD name constructed would be 
ILR35 ) - This is accomplished by obtaining the number of volumes 
and looping through to append the next volume num b er until the 
count of volumes in register RC is diminished to zero. Control 
then falls through to location FNDJFCB1. 

At location FNDJFCB1 the DD name at location DSVOLS is moved 
to location DCBDDNAM in the data control block. The address of 
the exit list and the open flags are placed into the DCB, and the 
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DCB address is placed into location OPENP ARM. Tlie top byte of 
location OPENPARM is set to a hexadecimal 80 , indicating the end 
of the open list. An RDJFCB macro instruction has been issued to 
bring the Job File Control Block for this specified DD name into 
core au an addressable location. Addressability to the Data Set 
Control Block (DSCB) and the Job File Control Block (JFCB) is then 
provided through the use of USING assembler instructions. Next, 
the data set name is moved into the JFCB, and if the data set is 
qualified, a branch is taken into location SETJFCB1. If it is 
not qualified, location JFCBIND2 is set to indicate a shared data 
set (JFCBISHB), and a branch is taken to location SETJFCB2. At 
location SETJFCB1 , JFCBIND2 is set to indicate an old data set 
(JFCBIOLD); control Then falls through to location SETJFCB2 . 

At location SETJFCB2, the data set organization indicator 
is moved from location PDSORG in the user’s supply parameter 
area to location JFCBSORG in the Job File Control Block. The 
volume count of this data set is loaded into register RCTR from 
location WORKAREA in the DSCB for this data set. This number is 
stored both in location JFCBNVOL , which holds the number of volume 
serial numbers , and in location JFCBVLCT . Using the count in 
register RCTR, the volume serial numbers are then moved from 
location WORKAREA + 2 in the data set control block work area to 
location JFCBVOLS by looping through decrementing register RCTR 
until register RCTR is zero. The key length for the data set is 
then moved from location DS1KEYL in the DSCB to location DCBKEYLE 
in the data control block. The data set organization is likewise 
moved into the data control block at location DCBDSORG, and the end 
of the data address is moved from the parameter area from location 
PEODAD to the data control block at location DCBEODAD. The record 
format for this data set is moved from location DS1RECFM in the 
Data Set Control Block to location DCBRECFM in the data control 
block. The data set organization specified in the user’s parameter 
area at location PDSORG is tested for an index sequential data set 
(PBITIS). If this is not an index sequential data set, a branch is 
taken to location SETDCBO. If it is, location PMACRF + 1 
in the user’s supply parameter area is tested to see if the TMSGTSLE 
flag is set (a hexadecimal 80 ) . If it is not set, a branch is taken 
to location SETDCBO. The setting of this flag means that the user 
is going to employ the queued index sequential access method, which 
requires the loading of the service module TMSGTSLE. If the flag 
is set, location PMACRF (the user’s macro instruction references) 
is moved to location DCBMACR in a data control block. Location 
DCBMACR + 1 is ANDED with a hexadecimal value of 7F to turn off the 
TMSGTSLE flag in the data control block. This flag is used only by 
the TMSOPEN routine. A standard linkage is then set up to the routine 
TMSPLOAD with register 1 pointing to a location containing the name 
TMSGTSLE. Before a linkage to this routine is established, the 
registers saved by TMSOPEN at location FBSAVE are temporarily stored 
in location TEMPSAVE, Then a standard BALR instruction is issued. 

Upon return from the TMSPLOAD routine, the registers at location 
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TEMPSAVE are restored to location FBSAVE, and the success or failure 
of the loading of the routine TMSGTSLE is determined by testing 
register RC for the presence of a zero. If register RC is not 
zero, the program was not loaded successfully, and a branch is 
taken to location NOCORE 3. If it is successfully loaded, the entry 
point of the routine currently in register RPO is stored at 
location CRGTSLE in the communication region. A branch is taken 
to location SETDCB0 + 6 to avoid repeating the macro reference 
field's move to the data control block. 

At location SETDCBO the macro instruction reference parameter, 
which the user supplied at location PMACRF in the parameter area, 
is moved to location DCBMACR in the data control block. Location 
PMACRF is tested for the presence of a bit indicating EXCP access 
method (PBITE). If it is present, a branch is taken to location 
SETDCB2. Otherwise, the option codes at location POPTCD are moved 
to location DCBOPTCD from the user's parameter area to the data 
control block. Likewise, the synad routine address supplied by 
the user at location PSYNAD is moved to location DCBSYNAD. If this 
is not an index sequential data set, a branch is taken to location 
SETDCB1. If i . is an index sequential data set, the numeric 
portion of location PARMFLGS is moved to location DCBMAC for the 
index sequential macro Instruction reference extension. Then, the 
relative key position is moved from location DS1RELKP in the Data 
Set Control Block to location DCBRKPN in the Data Control Block. 

At location SETDCB1 the blocksize is moved from location DS1BLKL 
to location DCBBLKSI (all locations starting with the prefix DS1 
indicate that this location is in the Data Set Control Block; 
likewise, locations starting with the prefix DCB indicate that this 
location is in the Data Control Block). The data set organization 
at location PDSORG is tested for a bit indicating a direct access 
data set (PBITDA). If this is a direct access data set, a branch 
is taken to location SETDCB3. If not, the logical record length is 
moved from location DS1LRECL to location DCBLRECL, and then a 
branch is taken to location SETDCB. At location SETDCB2, location 
PMACRF is tested for a bit indicating that appendages are required 
with the EXCP access method (PBITAPP)* If appendages are not 
required, and this bit is not present, a branch is taken to 
location SETDCB3. Otherwise, location POPTCD specifying the option 
code is moved to location DCBOPTCD; likewise, the appendage 
identification codes are moved from location PAPPIDS to location 
DCBEOEA. Control then falls through to location SETDCB3- 

Here location PMACRF is tested again to see if the EXCP access 
method is specified and, if so, a branch is taken to location 
OPEN. Otherwise, location PARMFLGS is tested to see if the user 
wants to prevent buffer generation (PNOBUFFS). If the user does 
want buffer generation prevented, a branch is taken to location 
BUFFERU. Otherwise, the blocksize for this data set is loaded into 
register RW0RK1 from location DCBBLKSI. The quantity now in 
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register RW0RK1 is made into an integral number of doublewords 
"by appropriate ri gbi t and left shifts- Location PD30RG is tested 
for a "bit indicating an index sequential, data set. If this is 
not an index sequential data set, a branch is taken to location 
BUFFERl. If it is an index sequential data set, the key length of 
the record is obtained. Ten "bytes for the length field and 
15 "bytes for the padding are added to the key length and then 
rounded down to a multiple of 8. This quantity is added to 
the "basic "buffer length in register RWORKl^ a nd control falls 
through to location BUFFERl . At location BUFFERl, the "buffer 
length currently in register RW0RK1 is stored at location DCBBUFL. 
The quantity in register' RW0RK1 is incremented "by 8 "bytes for the 
"buffer control "block, and "buffer alignment is tested "by examining 
location DCBBFLAN to see if the user has specified fullword, 
rather than doubleword alignment. Ir the user has not specified 
fullword alignment,, a "branch is taken to location BUFFER2. If 
he did specify fullword. alignment, register RW0RK1 is again 
incremented "by 8. Control then falls through to location BUFFER2 
where the "buffer size is transferred to register RPO, and a 
GETMAIN macro instruct! on is issued specifying that this length "be 
obtained. The success of this GETMAIN is measured by testing reg- 
ister RC for a return code of zero. If this register does not 
contain zero, a branch is taken to location N0C0RE3. If the 
GETMAIN was successful, the address of the core obtained is stored 
at location DCBBUFCB, and both the buffer control block and the 
pointer field of the first buffer are cleared to zeros. A buffer 
count of 1 is placed in both the buffer control block and in the 
data control block at location DCBBUFNO. The buffer length is 
moved from location DCBBUFL to the buffer control block. The 
address of the first available byte past the buffer control block 
is obtained and put into register RW0RK1. Once again, buffer 
alignment is tested, and if fullword alignment is not requested, 
a branch is taken to location BUFFER 3 . If it is requested, the 
address of the first available byte is incremented by four to point 
to the first fullword past the buffer control block that is not 
also doubleword alignment. Control then falls through to location 
BUFFER 3 where the address of the first available byte is stored, 
not only in the first fullword of the buffer control block, but 
also at location FBSAVE plus 8 corresponding to register RPO. A 
branch is then taken to location OPEN. If, at location BUFFERU, 
the user specifies prevention of the buffer generation, a 
hexadecimal 01 is moved, to location DCBBUFCB + 3 to indicate no 
buffers. Control then falls through to location OPEN where a 
GETMAIN is issued to see if enough remains for the resident OPENJ 
processing routines. The normal completion of these GETMAINs 
is determined by testing for the presence of a 0 return code in 
register RC. If the return code is not 0, a branch is taken to 
location N0C0RE3. If it was successful, a FREEMAIN macro instruc- 
tion is issued to release the core obtained by the GETMAIN, and 
then an OPEN macro instruction type J is issued. On return from 
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this macro instruction, DCBOFLGS is tested for a hexadecimal 10, 
which indicates that the OPEN was unsuccessful. If there is no 
hexadecimal 10, a branch is taken to location DISASTER to indicate 
the failure of the OPEN. However, if it was successful, register 
RDCB containing the address of the data control block is stored 
at location FBSAVE + 12 corresponding to register RP1. Location 
PMACRF + 1 is tested for a hexadecimal 80, which indicates that 
this data control block is for the queued index sequential access 
method. If this bit is not present, a branch is taken to location 
RETURN. If it is present, the top bit of location DCBMACRF + 1 
is turned on to tell the CLOSE routines that the module TMSGTSLE 
is resident and must be deleted. Control then falls through to 
location RETURN, where- a return code of 0 is loaded into register 
RC. Control then falls through to location RETURN1 , where 
register RC is stored in location FBSAVE + 4, which corresponds 
to register RC . A standard return of LM and BR instructions are 
used. 



At location CMISSING corresponding to location VMISSING, 
register RP1 is loaded with a value of l6 , register RC is loaded 
with a return code of 4, and a branch is taken to location PURGE. 

At location N0C0RE1, the core for the buffer pool must be freed. 

The necessary freeing of the core for the buffer pool is done at 
location N0C0RE1 by obtaining the pointer to the buffer pool from 
location DCBBUFCB; finding from this location the number of buffers; 
multiplying this number of buffers by the buffer size; testing 
for fullword alignment and, if fullword alignment was specified, 
adding 8 bytes; adding 8 bytes for the buffer control block; and 
freeing the core of this size with the use of a FREEMA.IN macro 
instruction. Control then falls through to location N0C0RE3, 
where the DCB length is loaded from location DCBELMLN. The address 
of the data control block from location FBDCBCHN, the data control 
block chain, is updated by moving the current entry in the chain 
to location FBDCBCHN. A FREEMAIN macro instruction is then issued 
for the core held by the data control block. At location N0C0RE4, 
register RP1 is loaded with a value of 20, register RC is loaded 
with a return code of 8, and a branch is taken to location PURGE. 

At location DISASTER, register RP1 is loaded with a value of 24, 
register RC is loaded with a return code of 12, and a branch is 
taken to location PURGE. 

At location PURGE, location PARMFLGS is tested for a value of 
hexadecimal 80 , indicating that the user wants control to return 
to himself with the relevant condition code should anything fail 
in the TMSOPEN routine * If this bit is present, a branch is taken 
to location RETURN1. Otherwise, register RC is loaded with the 
entry point of the routine TMSPURGE, and a branch register instruc- 
tion if taken on register RC . 
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h . 10 TMSP JOB Module 



The TMSP JOB module has only one entry point, and its charac- 
teristics are somewhat different from those of other entry points • 
The primary distinction is that permanent addressability is set 
up in register 12 (RB) prior to entry into this routine. This is 
done because initial entry into this routine is not made by a 
specific branch from another routine. Instead, this routine is 
dispatched for this particular FB as if some third routine has 
caused the posting of a wait, simulated to have occurred just 
before the beginning of the phantom job code. 

Since the base register, the FB pointer, and the CR pointer 
are all assumed to have their proper contents when entering TMSPJOB, 
addressability is established immediately by means of the necessary 
USING instructions. R-type GETMAIN then is issued for a 72-byte 
area which will become the topmost save area for the FB pointed 
to be RFB. This entire new save area is cleared, and the FB 
pointer then is stored in the first word so that it may be propa- 
gated to succeeding save areas by code generated by the TMSSAVE 
macro instruction. The TMSCSIO macro instruction is then invoked 
to write the message: 

TMS100I - TMS IN OPERATION 

to the terminal associated with the current FB. Control then 
passes to the next block of code. 

The next major section of code headed by the label LOGIN asks 
for, receives, and then processes the user's identification code. 

A call is first made to the console I/O routine to issue the 
message : 

TMS101A - WAITING FOR LOGIN 

to the terminal involved. This issuance is followed immediately 
by a request to read a response from the terminal. A check is 
first made to see if the response is the word DISCONNECT, which 
indicates that the user wishes the terminal logically disconnected 
from the system. If this match is true, a branch is made to the 
code at label DISCONCT which issues a WTO to write on the console 
typewriter the message: 

TERMINAL nn DISCONNECTED BY USER 

where nn is the terminal number in ECBDIC which has been generated 
by the TMSHSKP routine and placed in the function block at FBTERMNO. 
The terminal disconnected flag FBDSCNCT is set on in FBFLAGS. Then 
the FBECB first byte is set to all zeros, and the macro TMSWAIT 
is invoked. Since there is no outstanding operation to post the 
FBECB complete, this effectively puts the terminal in a permanent 
wait condition. If the response from the user terminal is not the 
word DISCONNECT It is assumed to be a user identification code. 

The last non-blank character in the reply is found. Since this 
is assumed to be the EOT character, it is set to blank in order not 
to Interfere with comparisons of responses which have three charac- 
ters or less with the table of authorized user identification codes. 
The valid user identification codes are found in the list labeled 
USERLIST. The number of entries in this list is placed RCTC, and 
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the address of the first entry in the list is placed RPTR. Prior 
to a check of the user list, however, a pass is made down the FB 
chain to see whether the user ID that has teen sent hack is 
identical to the contents of FBNAME in any FB. If an Identical 
match is found, the message: 

TM103I- NOT ACCEPTED, NAME ALREADY IN USE 

is sent to the user terminal, indicating that acceptance of the 
user ID as supplied would result in duplicate concurrent user ID 
names. A branch is then taken hack to LOGIN to reissue the 
invitation to log-in and read a new response from the terminal. 

If the user identification code does not duplicate the code found 
in any other FB, a loop is. executed to compare the user ID code 
against a list of valid user ID codes. If this loop is exited with- 
out a match, the message: 

TMS102I- NOT ACCEPTED 

is sent to the user terminal, and a branch is taken to LOGIN to 
invite another attempt to log-in. If there is a match, the branch 
is taken to ULCHECK2 where the user name is moved to FBNAME , and the 
message : 

TMS102I- nnnn LOGGED IN 

is sent to the user terminal with the user name in place of nnnn. 
Control then falls through to the next block of coding. 

The next section of coding beginning with the label SPECIFY 
determines which program the user wishes to execute under TMS and 
brings it into main storage if there is enough space. This routine 
first issues the message: 

TMSIOUA- SPECIFY PROGRAM 

to the user terminal and then reads the response. When a response 
is received, a check is made first to see whether the initial 6 
characters of the response equal the word LOGOUT. If so, a branch 
is taken to location LOGOUT, where the message: 

TMS105I- nnnn LOGGED OUT 

is sent to the user terminal with the user name replacing nnnn. 

The area FBNAME is then restored to blanks, and a branch is made to 
LOGIN to invite log-in by the next user. If the response is not the 
word LOGOUT, the first eight characters of the response are assumed 
to represent the name of a program in the TMS library. As in the 
log-in routine, the last character of the response message is changed 
from EOT to blank in order not to interfere with comparisons. The 
pointer to the program name in register 1 (RPl) is also copied into 
register 0 (RPO) to save it. The address of the TMSPLOAD module is 
then found from the communication region, and a subroutine call is 
made to this routine. Upon return from this routine, the completion 
code may have one of four values. A completion code of zero indicates 
a successful load of the program. Branches are made to the code 
labeled ENTER. ENTER moves the program name in the reply buffer to 
the double word FBPNAME to be used later in deleting the program, and 
then it enters the program as a normal subroutine call. A return 
code of four from the program load routine means there is not enough 
main storage to complete the load; in this case a branch is taken to 
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NOCORE where the message: 

TMS109I- NOT ENOUGH CORE TO LOAD PROGRAM 

is sent to the user terminal, and a branch is taken to SPECIFY to 
invite the user either to respond with the name of another program 
or to log-out. A completion code of eight upon return from the 
program load routine indicates that a specified load module could 
not be found in the library. A branch is taken to the code labeled 
NOMODULE where the message: 

TMS107I- PROGRAM NOT FOUND 

is sent to the user terminal, and a branch is made either to 
SPECIFY to invite another try to spell the program name, properly 
or to load another program. A completion code of twelve upon 
return from the program load routine means that a program with the 
specified name was already found in main storage but was found not 
to be a re-enterable module. In this case- a branch is taken to 
the code labeled NONRENT, where the message: 

TMS108I- PROGRAM NOT RE-ENTERABLE AND ALREADY IN USE. WAIT OR TRY 
ANOTHER 

is sent to the user terminal, and a branch is made to SPECIFY 
to allow the user to try another program or log-out. If there is 
a completion code of l6 from the program load routine, there is a 
severe input/output error in attempting to load the program. A 
branch is taken to the code labeled IOERROR, which consists of a 
halfword of binary zeros • This will force an immediate program 
check and abnormal termination with a dump. 

As mentioned previously, in the normal sequence of events the 
program is located successfully and loaded into storage, and a 
subroutine call is made to the program from the TMSPJOB module. 
Normal termination of the user program consists of a standard 
subroutine return via a register ik (RR) . A normal return via the 
TMSPURGE module is a return to a point U bytes past the point 
indicated by the contents of register l4. In TMSPJOB, the two 
full words immediately following the BALR used to enter the 
applications program consist of a branch instruction to the code 
labeled NORMAL followed by a branch instruction to the code labeled 
PURGED. The code labeled NORMAL checks the pointers FBBLKCHN 
and FBDCBCHN to see that all storage obtained by the application 
program has been released and all DCBs opened by the application 
program have been closed. If either or both of these criteria are 
not met, a branch is made to the code at PURGE which executes a 
subroutine call to TMSPURGE with a value of k in the error index 
parameter supplied in register 1. Control then drops through to 
the code with the label PURGED. If the above criteria have been 
met, control passes on to code which writes the message: 

TMS106I- NORMAL EXIT FROM USER PROGRAM 

on the user terminal. Control continues on to code labeled DELETE, 
which issues a DELETE EPLOC macro instruction with- the contents of 
FBPNAME as parameter, thus deleting the application program and 
and removing it from main storage if necessary. This delete 
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operation is followed by both the clearing of FBPNAME to blanks 
and a branch to SPECIFY to ask the user to either specify a new 
program or dog-out . 

There are two ways the TMSPJOB detects that some form of 
error has occurred during operation of the application program. 

The first Is the return to TMSPJOB from TMBPURGE by an offset of 
4 bytes from the normal return point . The other is a normal 
subroutine return from the TMSPURGE routine that was directly 
invoked by TMSPJOB at location PURGE. In either case control 
eventually passes to the code labeled PURGED, which issues the 
message : 

TMSX10I- ABNORMAL RETURN FROM USER PROGRAM VIA PURGE ROUTINE 
and takes a direct branch to the code labeled DELETE to delete 
the program that had been loaded. 

4.11 TMSPLOAD Module 

The function of the TMSPLOAD module is to load a user program 
at the request of another TMS module. TMSPLOAD begins by storing 
the calling module T s registers in the FBSAVE area and setting 
the TMSPOLOAD entry flag on. The name of the program to be loaded, 
which is pointed to by register 1 (RPl), is then stored into the 
BLDL list. TMSPLOAD then checks to see if sufficient core is 
available for the BLDL routine ( 406 bytes). If core is not avail- 
able, control is returned to the calling routine with a completion 
code of 4 in register le (RC) . Otherwise, the BLDL (SVC8) is 
issued, and the load list is built. If the BLDL returns with a 
completion code of 8, control is returned to the calling module with 
a completion code of 16 in register 15- This indicates that a 
permanent I/O error was detected during the directory search. 

If the BLDL returns with a completion code of 4, control is 
returned to the calling module with a completion code of 8 in 
register 15. This indicates that the requested module could not 
be found. If the BLDL returns with a completion code of 0, 

TMSPLOAD searches the FBCHAIN for an already-loaded copy of the 
program. If it finds a copy loaded, and the program is flagged 
not re-enterable , control is returned to the calling module 
with a completion code of 12. This indicates that the load request 
was for a not re-enterable module that was already loaded. If 
TMSPLOAD finds a copy of the program loaded, and the program is 
flagged re-enterable, the program is loaded via the load SVC (SVC8), 
which merely bumps the use count by one. The entry point of the 
loaded module is then stored in the FBSAVE area for the terminal 
requesting the load, and control is returned to the calling module 
with a completion code of zero. 

If no copy of the requested program is found in the FBCHAIN, 
TMSPLOAD checks to see if sufficient core is available to load 
a copy of the requested program plus the forty (40) bytes required 
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for the associated request block.. If core is not available, control 
is returned to the calling module with a completion code of U. 
Otherwise, t he program is loaded, vi-.a the load SIC (SVC 8), the enter 
point is stored fw the FBSA"VE area, and control rs returned, to tie 
calling module "with, a return cade of zero. 

It. 12 TMSPURGE Module 

The function of TMSPURGE is to- delete a user pragrar currently 
running on one of the terminals free all storage gnnnren by the 
user program and close all files opened by it. Since control will 
not he returned to the user after TMSPURGE, the user’s registers 
are not saved. Upon entry, the TMSPURGE entry flag is set on. 

Next the pointer to the message indicating the reason for entering 
PURGE is set up using the offset received in register 1. The save 
area chain is then traced to the highest save area, and the registers 
are restored to their condition prior to entering the program being 
purged. 

PURGE then begins closing all attached DCB's by following the 
DCB chain (FBDCBCHN) located in the FB and entering TMSPCLOS with 
all of the DCB addresses on the chain. The end of the DCB chain 
is indicated when FBDCBCHN equals zero. When all DCB's are closed, 
PURGE begins freeing all attached storage areas obtained by 
TMSGETM by following the storage chain (FBBLKCHN) located in the 
FB. 



When all attached DCB's are closed and all attached storage is 
freed, the error message indicating the reason for entry to PURGE 
is displayed. This is followed both by computing the relative 
address of the error detected and by displaying the error location 
message. Finally, control is given to TMSPJOB with an offset of 
four from the normal return point to PJOB. This results in 
deleting the user program and displaying the abnormal return from 
user program via PURGE routine message, followed by the request to 
specify program. 

The messages issued by TMSPURGE are as follows: 

TMS150I - PROGRAM ENDED WITH STORAGE OR DATA SET STILL ATTACHED. 

TMS15H - INSUFFICIENT MAIN STORAGE LEFT TO SATISFY TMSGETM REQUEST 
TMS152I - TMSFREEM REQUEST DOES NOT SPECIFY LEGITIMATE ADDRESS 
TMS153I - ATTEMPT TO OPEN AN UNAVAILABLE/UNCATALOGED DATA SET 
TMS154I - INSUFFICIENT MAIN STORAGE LEFT TO COMPLETE OPEN OF A DATA SET 
TMS155I - DISASTROUS ERROR IN TMSOPEN 

TMS156I - TMS CLOSE REQUEST DOES NOT SPECIFY LEGITIMATE ADDRESS 
TMS157I - END OF DATA DETECTED WITH NO EODAD SPECIFIED 
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TMS15SI - SHC HZ5IIHDUS IEROH DETECTED WITH NO 3YNAD SPECHIED 
T "31591 — INSUIT-OIErJT CORE LEFT /OR DEBUGGING 
TUI16QI - ERROR DETECTED IN TMS, USER PURGED WITH SNAP 

I IlolZ — ERROR DETECTED IN TMS- USSR PURGED. SNAP UNSUCCESSFUL 

1.1.16.21 - ERROR DETECTED IN PROGRAM. USER PURGED. 

PEL 10 01 - ERROR OCCURRED AT RELATIVE LOCATION XXXXXXXX 

1 . 15 TM5TREND Modulr- 

The TMS TREED module has two entry points. The main entry 

po int is TMSTREND, which is used for entry into the program from 

TMSWAII when an input— amtput operation for the communication line 
is complete. The seconi entry point, TMSCHEND , is a simple BR 
return through register U_5 (RF) , and is net called "by any other 
TMS module . 

Since control is passed only to and from other TMS modules, 
the user’s registers are not saved on entry. TMSTREND assumes 
that on entry register 1 (RPl) points to the DECB for the communi- 
cation line, and after establishing permanent addressability, 
establishes addressability for the DECB and corresponding DCB for 
the line, the FB , and the CR. 

After initialisation of the appropriate base registers , the 
DECB is checked to see which operation was in progress so that 
either the address of the polling characters may be found for a 
read, or the addressing characters may be found for a write. In 
either case, unless there is only one terminal, a skip bit is 
set in the current polling entry vnose address is found at 
location DEC PO LPT or DECADRPT in uhe DECB. 

The next section of code, starting at location CEENTRY2 
after the skip bit has been set, locates the FB for which the 
operation is complete. This is done first by loading register 
RW0RK2 with the address of the terminal list from location DECT- 
L1ST in the DECB, and then subtracting it from register KW0RK1, 
which was previously loaded from either DECPOLPT or DECADRPT. The 
result in RW0RK1 is the offset to the terminal list entry, which 
is compared to the offset specified at location FBTLOFF in the 
current FB being processed. If equal, the proper FB has been found, 
and a branch is taken to CEENTRU. If it is not the proper FB, a loop 
is executed to follow the chain of FB’s to the end, checking each 
one. If no proper terminal offset is located, an ABEND is executed 
with a user completion code of 777, and a code of 50 is placed 
at location CRABCODE in the CR. 

Once the FB has been located, the buffer address is loaded 
into register RBUF from DECAREA and documented by four to point 
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to the "buffer contm.l word. Location LECIJFLAGS is then tested to 
find which operation was in progress , and a branch is taken to 
either CEREAL or CEWRITE for corresponding read or write operations. 
If LECUFLAGS indicates either both or neither operation in progress, 
a 51 or 52, respectively , is placed in CRABCOLE, and ABEND is 
issued. 

The code at location CEREAL begins by checking that the flags 
in the buffer control word indicate buff er-in-use (BUFFINUS) and 
buffer-waiting- for- input (BUFFWTXftf) before proceeding. If these 
flags are not set, a 53 3-S placed in CRAB COLE,- and an ABENL is 
issued. Then location LEC FLAGS is tested for negative response 
(LECFEEGR) which indicates that channel end is due to polling 
reset. If this flag is on, a branch is taken to CEREAD5 ; if this 
flag is off, there is an incoming message. Register RBUF is then 
incremented by four to point past the buffer control word to the 
start of the message. The maximum length of the message is loaded 
into RCTR from LECLNGTH, and the residual count at LECCOURT is 
subtracted from it to find the actual length stored at FBLMLNTH 
in the FB. This length then is used also to translate the incoming 
message. If there are multiple terminals, the pointer to the mess- 
age is spaced over the header and the length adjusted by four. 

At CEREAL3 the buffer address is stored in FBBUFPTR, and the 
text offset is computed by a simple subtract and stored in 
FBBUFOFF. The buffer flags indicating waiting for input are turned 
off (BUFFWTIN), and buffer attached to FB (BUFFATFB) are turned on. 
The LECUFLGS are reset to turn off read in progress (LECUFRIP) and 
polling reset (LRCUFPRS). The active polling count is reduced by 
one if there is more than one terminal, and a positive acknowledge 
is written to the sending terminal. A return is made to entry 
point TMSLWAIT in the TMSWAIT module. If there are not several 
terminals on the line, at location CEREALY , the completion code is 
moved to location FBECB. Location LECSLECB then is set to zero, 
and a return made to entry point TMSLWAIT. 

If channel end is due to polling reset, control passes to 
location CEREAL5 where flags at LECUFLGS are tested for read-in- 
progress, waiting-to-write and polling-reset (LECUFRIP, LECUFWTW, 
and LECUFPRS). The negative response flag, skip hit, read-in- 
progress flag, and polling-reset flag are turned off, and the poll- 
ing interrupted (LECUPIN) flag is turned on. The line ECB is zeroed, 
and the operation type, buffer length, buffer address, terminal 
polling list address 5 and relative line number are stored at 
location LRCRSAVE to be available for later polling restart. The 
dummy ECB in the CR is then set to indicate operation complete and 
line available for write, and a return to TMSLWAIT is made. 

If the operation tested at CEENTRYU is a write , control passes 
on to location CEWRITE. The type of operation flag at location 
LECTYPE+1 is tested to see if the operation is a write positive 
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acknowledge. If* it; is, control p^ssss ±0 CEWRITE7, where the 
write In progress and acknowledge Hags are turned off. The 
conpletion code is moved to locating F3ECB, the line ECB is 
zeroed, and a branch is taken to 1EWHITE3. If the operation is 
not a write positive acknowledge , t±ee completion code is moved 
to the FB ECB, and the line ECB (IDEC3DECB) is zeroed. The buffer 
pointers are reset and the ruffe r Is filed with blanks. The write 
in progress flag is reset and, if a transmission error is being 
processed, comt-rol is passed, to CEWEITE7 to process as a positive 
acknowledge. Otherwise, at CFWHITE3 there is a test to see if a 
write is queued for the line by marking location DECUFLGS with 
DECUFWTW. If a write is queued, a return is made to TMSDWAIT. 

If a write is not waiting, DECUFLGS is marked to test for polling 
interrupt. If polling was interrupted, control moves to CEWRITE5. 

If not, the active polling count (DECAPCNT) is tested for zero. 

If there are no other reads ±n progress, a return is made to 
TMEDWAIT ; otherwise, a return is made to the read polling restart 
routine (TMSRDRST) . 

At CEWRITE5 the polling interrupt flag is turned off, and the 
operation code, buffer length, buffer address, terminal polling 
list address, and relative line number are restored to the data 
event control block. The read- in-progress flag is set, and a 
READ macro instruction is issued for the line. Control then 
returns to TMSDWAIT. 

If, at CEENTRYU, a transmission error is detected, control 
passes to location CEERROR. If the error already is being 
processed, and it is the second time through, control passes to 
an ABEND macro instruction with a 58 placed at location CRABCODE. 

The data event control block channel status word status is tested 
for channel end, device end, and unit check flags, and if not 
present, control is passed to ABEND with a 59 in CRABCODE. The 
data event control block fiust sense byte (DECSENSO) is tested for 
timeout, lost data, or data check and, if any are indicated, a branch 
is taken to CEERR0R2. If none are indicated, control passes to 
ABEND. At CEERR0R1, the transmission error flag at location FBFLAGS 
(FBXMTERR) is set, and the read or write in progress flag and the 
skip bit are turned off. The FB ECB is then posted complete with 
the error, the line ECB is zeroed, and a return is made to TMSDWAIT 
via CERETURN. 

The return and location CERETURN is a simple load of a V-type 
address constant specifying the entry point TMSDWAIT into register 
RR, followed by a simple branch register on register RR. 

h.lh TMSWAIT Module 

The TMSWAIT module has two principal entry points . The 
first entry point, TMSWAIT, is used for entry into the module from 
application programs. A subsidiary entry point, TMSDWAIT, is 
used as a direct entry into the wait module, bypassing certain 
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register saving and restoring conventions used in calls from 
application programs. Depending on th-e status of* the *vrait list, 
this module may exit to an application program - th.e TMSCTSL 
module to process a message from the computer -operator, the 
TMSCSIO module to initiate console input-output for a newly-freed 
line , or the TMSTREND module to perform end-of-transmission 
processing for a communication line which has just finished its 
I/O task. 

On entry through entry point TMSWAIT from an application 
program the contents of registers lU (RR) through 12 (RB) are 
stored temporarily in the save areas pointed to hy register 13 
(RS). The address of the RB is obtained from word zero of this 
save area. Once FB addressability is established, the contents 
of the registers which were saved upon entry are moved to the 
corresponding FBSAVE. At this time the contents of register 13 
are also saved in FBSAVE. Permanent addressability to the wait 
module is established, and the CR address is loaded into register 
10 (RCR) from FBCR. The code beginning at location ENQUEUE places 
the ECB address supplied in register 1 (RPl) onto the end of the 
wait list. This is done by loading the address of the last wait 
list entry from location CRWLLAST into register FLAST , increment- 
ing by k , and using the resulting address to store the new ECB 
address into the wait list. The contents of CRWLX, the wait list 
offset, are added to RLAST to find the correspoiding area in the 
wait list extension. The FB address is stored in this area. The code 
beginning at location WAIT sets the end- of -wait-list indicator into the 
high order byte of the current last word of the wait list. The pointer 
to the wait list in area CRWL is put into register 1, and the WAITR 
ECBLIST macro is issued to relinquish control of the computer if no 
operation has been completed. 

Either immediately or when one wait condition is satisfied, 
control falls through the code labeled ENDWAIT. This begins to 
search the wait list for the first completed event control block. The 
first operation is to reset the end-of-wait-list indicator. The 
console ECB address is then loaded into a register, and the setting 
of the completion bit is tested. If this bit is on, a branch is taken 
to location CONSOLE. The code at this area both loads the address of 
the system save area (entry point TMSSYSSB in the TMSBEGIN module) 
into register 13 (RS) and takes a standard entry into the TMSCNSL 
module via the entry point of the same name. 



If the console ECB is not yet complete, the queuing ECB is 
tested. If the completion bit is set in this ECB, a branch is taken 
to location FBQPROC . The code at this point employs repeated calls 
to subroutine DEQUEUES both to find the first FB on the FBQ chain 
waiting for newly-freed resource and to remove that FB from the Q 
chain. This is done as follows: the resource freed for use is 

identified by a bit in location CRECB. When this bit is found set, 
three masks are set up for the use of the dequeuing subroutine. 
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They are QFLAGCR for testing location CRQFLAGS, QFLAGFB for testing 
location FBQFLAGS, and UFLAGDEC. for testing location DECUFLAGS. 

The subroutine DEQUEUES is linked to, losing RRET as an internal 
return register. Upon return from this subroutine, register RFB 
is tested for non-zero. A non-zero return indicates a successful 
dequeuing and a branch is taken to the appropriate routine. A 
zero indicates that no FB vas found to be queued on the free 
resource. In this case the corresponding flag is turned off in 
CRECB, and a branch is taken to the next test. Two tests of the 
FB queue chain are now implemented. The first is for a line now 
free for a write operation. If the FB requiring this resource is 
found, a branch is taken to the entry point TMSWRDEQ in the 
TMSCSIO module to initiate writing on the line. The other test 
that is now made is for a line that is free for a read operation. 

If an FB queued on this resource is found, a branch is taken to 
the TMSRDRST entry point of the TMSCSIO module to initiate a poll 
restart. In the event that any of the preceding tests do not 
succeed, there is an error condition, and the first byte of 
location CRECB is cleared to all zeros. A branch then is taken 
back to location WAIT to continue processing the wait list. 

After the special processing of the first two ECB addresses, 
the remainder of the wait list is searched for the first ECB with 
these completion bit sets by means of a simple loop. The comple- 
tion bit is set on for at least one ECB, since failure for this 
being done would indicate a gross error on the part of the operat- 
ing system. Therefore, whenever further wait list processing is 
to be done, and if it is not certain that there are any further 
ECBs with completion bit set, return should be made to location 
WAIT for a further reissuing of the WAIT macro to 0/S. When the 
first completed ECB is found, it is necessary to determine whether 
this ECB represents a physical communication line or a logical 
terminal. This is done by checking the first byte of the corres- 
ponding fullword in the wait list extension for a bit pattern 
consisting of all one bits. If this pattern is found, the ECB 
in question represents a communication line, and entry is made to 
the TMSTREND entry module via the entry point of the’ same name to 
process the end-of-transmission condition. If this special bit 
pattern is not found, a branch is taken to code at location DEQUEUE, 
which loads the address of the corresponding FB into RFB from the 
wait list extension. If necessary, all ECB addresses in the wait 
list and their corresponding FB addresses in the wait list exten- 
sion are moved up to fill the space vacated by removel of the ECB 
and FB addresses from the wait list. Following this, register 
RLAST is decremented by h to reflect the shortening of the wait 
list. Finally, the contents of all registers are reloaded from the 
proper FBSAVE , and the return to the application program is taken 
through register 1*+ (RR). 

The entry point TMSDWAIT is used for entry into the wait 
routine from other elements of the monitor system. Its principal 
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purpose is to avoid, the saving of* registers in FB5AVE, since 
entry is not from an application program. After setting up a 
“base register pointing to tlie “beginning of the TMSWAIT module 
in establishing permanent addressability , the code for this entry 
point loads register BLAST from location CRWLLAST and branches 
directly to the code at location WAIT. Upon entry to the wait 
module via this entry point, register 10 always will point to 
the CR. 
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5. DETAILED MACRO DESCRIPTIONS 



5.1 FORMFB Macro 

The FORMFB macro employs three global variables- The arith- 
metic variables, &FBNO and &TERMNO, are used to maintain a running 
count of the number of FB T s and terminals that have already been 
defined by previous invocations of FORMFB- Proper usage of these 
two variables depends upon an uninitialized arithmetic global 
variable having value 0 when first used- The global character 
variable &PREVFB is used to contain the name of the last function 
block generated by the most recent previous invocation of FORMFB. 

A test is made to see if this name is null, the initial value of a 
global character variable. If it is, it is set to the character 
"0", so that when it is employed in an A-type address constant, 
the proper result will be obtained. 

The first operations in the macro-expansion are to identify 
the type of terminal being employed and to set certain parameters 
to be used in the remainder of the expansion- The types currently 
recognized are: l) M35D: a model 35 teletypewriter attached via 

a direct link; 2) 27^0B: an IBM 27^0 basic terminal; and 3) S720W: 

a Sanders 720 CRT terminal with horizontal screen and the special 
extra-width option. The local variables that are dependent upon 
the terminal type are: &DECTTYP, a local arithmetic variable used 

in setting byte type flags; &DECCPNL, a local arithmetic variable 
representing the number of -characters per second of carriage travel 
during carriage return; &DECMAXL, a local arithmetic variable repres- 
enting the maximum number of lines per page for page-oriented de- 
vices; &DECCPLN, a local arithmetic variable representing the 
maximum number of characters per line for the device; and &LISTTYP, 
a local character variable representing the form of polling list, 
to be expanded later in the macro - 

A standard Data Event Control Block (DECB) is generated by a 
list-type READ macro instruction, and a TMS-dependent portion 
is generated by a series of DC instructions. The Data Control Block 
(DCB) is generated by using the standard 0/S DCB macro instruction; 
the BTAM ine Error Control Block (LERB) is generated by using the 
standard 0/S BRAM LERB macro instruction; the terminal polling 
list is generated by using the standard 0/S BTAM DFTRMLST macro 
instruction; and the list of polling/addres sing characters is supplied 
by the LIST keyword operand. Following these tables, the buffers for 
this -line are generated. One buffer is generated for every FB. 

The buffers are linked together, and a pointer to the head of the 
link is placed in DCBBUFCB. The length of the buffers is determined 
by the BUFLGTH keyword operand, whose default value is 256 . Exit 
from the FORMFB macro is made with the global variables properly 
modified for use in a future invocation of FORMFB. 
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5.2 TABLES Macro 



The TABLES macro instruction is a Sanders-supplied macro which 
causes generation of an EBDCIC to ASCII-8 translate table and/or 
the generation of an ASCII-8 to EBCDIC translate table. These tables 
are used for translating messages sent to and received from Sanders 
displays . 



Name 


Operation 






TABLES 


EBCASC=namel [ ,ASCEBC=name2] 
ASCEBC=name2 [ ,EBCASC=namel] 



name 1 

Is any symbol valid in the Assembler Language. It will be 
generated as the name of 256-byte EBCDIC to ASCII-8 translate table. 

name 2 

Is any symbol valid in the Assembler Language. It will be 
generated as the name of the 256-byte ASCII-8 to EBCDIC translate 
t ab le . 

The macro instruction first checks to see if both parameters 
are omitted. If they are, the resulting mnote is * TABLES NOT 
GENERATED, PARAMETERS MISSING 1 . If one or both parameters are 
present, the macro checks for the absence of the EBCASC parameter. 

If the EBCASC parameter is absent, the mnote *EBCDIC TO ASCII-8 
TRANSLATE TABLE NOT GENERATED* is printed. Otherwise, the EBCDIC 
to ASCII-8 translate table is generated. The macro then checks 
for the absence of the ASCEBC parameter. If this parameter is 
absent, the mnote * ASCII-8 TO EBCDIC TRANSLATE TABLE NOT GENERATED* 
is printed. Otherwise, the ASCII-8 to ABCDIC translate table is 
generated. 

The translate tables which are generated are as follows in 
Fig. 5 

5.3 TMS CLOSE Macro 

The TMSCLOSE macro first checks for the existence of its 
single parameter. It then tests for both a leading left and trail- 
ing right parenthesis. If it finds these, a register designator 
is assumed. If this register designator is some standard represen- 
tation of register 1, the macro proceeds directly to the generation 
of the linkage code at sequence symbol ".LINK 11 , since the register 
specified is the register in which the parameters are to be passed. 
If a register other than register 1 is specified, the macro 
generates an LR instruction to bring the contents of that register 
into register 1. If the operand is not a register specification 
it is assumed to be -the symbolic address of a fullword in storage 
containing the DCB address. An L instruction is generated to bring 
this. address into register 1. Finally, the TMSLINK macro is used 



FIG. 5 

TRANSLATE TABLES 



* EBCDIC TO A3CII-8 TRANSLATE TABLE 
0123456789ABCDEF 
DC X'000102030U0000000800000000000000’ 0 

DC X ' 0011120000000000l8l90000001D0000 ' 1 

DC X ’OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO’ 2 

DC X '00000000000000000000000000000000 ' 3 

DC X'UOOOOOOOOOOOOOOO0OOOO9UE5Clt8UBOB' k 

DC X'U 6000000000000000000 UlUU^AU 95 B 0 D' 5 

DC X'UDl+F00000000000000001CUCi+51B5E5F' 6 

DC X'U3OOOO0OOOOOOOOOOOOO5AOCAOU75D*'t2' 7 

DC X ’00000000000000000000000000000000’ 8 

DC X' 00000000000000000000000000000000’ 9 

DC X* 00000000000000000000000000000000' A 

DC X'E1E2E3E4E5E6E7E8E9EAEBBBBCBDBEBF' B 

DC X'OOAIA2A3A4A5A6A7A8A9000000000000' C 

dc x'ooaaabacadaeafbobib2oooooooooooo' d 

DC X'OOOOB3BUB5B6B7B8B9BAOOOOOOOOOOOO' E 

DC X ' 505152535^+5556575859000000000000 ' F 



* ASCII-8 TO EBCDIC TRANSLATE TABLE 
012 3U56789ABCDSF 
DC X '0001020 30U00000008UA00UF7B5F0000 ' 0 

DC X'0011120000000000l8l900606AlD0000' 1 

DC X' 00000000000000000000000000000000' 2 

DC X '00000000000000000000000000000000' 3 

DC X'U05A7F705A6C507DUD5D5CUf6b6oUb61' k 

DC X'FOF1F2F3FUF5F6F7F8F97A5EUC7$6e6F' 5 

DC X '00000000000000000000000000000000' 6 

DC X '00000000000000000000000000000000 ' 7 

DC X '00000000000000000000000000000000' 8 

DC X' 00000000000000000000000000000000 ' 9 

DC X'7CC1C2C3CUC5C6C7C8C9D1D2D3DUD5D6' A 

DC X'D7D8D9E2E3EUE5E6E7E8E9BBBCBDBEBF' B 

DC X '00000000000000000000000000000000' c 

DC X '00000000000000000000000000000000' D 

DC X'OOBOBlB2B3BUB5B6B7B8B9BAOOOOOOOO ' E 

DC X'00000000000000000000000000000000 ' F 
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to generate the code that finds the entry point into the monitor 
for the close routine. The final instruction generated is a 
BALR RR, RC. 

5.4 TMSCSIO Macro 

The TMSCSIO macro employs the global binary variable &TMSRFB 
to find whether or not the problem programmer is maintaining the 
FB pointer in register 11 (R9). 

The principal work within this macro is the analyzing of 
the keyword parameter OP and the generation of the bit settings 
in the options byte. After initialization, the presence or absence 
of the LENGTH operand is determined, and the corresponding bit is 
set in the local arithmetic variable &OPCODE. The first OP sub- 
parameter then is tested for one of the four allowable operations 
(READ, WRITE, CLEAR, or REWRITE), and the corresponding bit is 
set in &OPCODE. After this, a loop is entered to scan the 
remaining sub -parameters , As each one is recognized, a correspond- 
ing bit is set in &OPCODE , and special flag bits are set to prevent 
the acceptance of a duplicate parameter. When all sub— parameters 
have been exhausted, the code generation portion of the macro is 
entered at sequence symbol ff .GENER ft . 

the principal operation is a WRITE, the positional operand 
representing the message is analyzed. If this operand consists 
of a string of characters delimited by apostrophes , the entire 
string is assembled in-line as the message text, preceded by a 
halfword message character count. A BAL instruction is generated 
both to skip over the message and to put its address into register 
(RP1). If the message parameter is determined to be a register 
designator , an LR instruction is generated to move the address 
into register 1* If the operand is a symbolic address, an LA 
instruction is generated to load the message address into register 
!• A* 1 improper or omitted message specification for a WRITE 

operation causes a zero length message to be supplied along with 
two level A error statements. The code is then generated to 
locate the FB (if necessary), to clear the first byte of FBECB to 
binary zeros, and to move a one-byte opcode into FBRWOP. For a 
CLEAR operation, register 0 (RPO) is cleared to zero. For any 
other operation, the LENGTH parameter, if present, is tested to 
see whether it is a register specification or a symbolic address, 
and either an LR or LA instruction is generated to load the length 
into register 0 (RPO). 

The TMSLINK. macro is invoked to generate the code that finds 
the entry point in the monitor of the console input /output routine 
following this. If the user has specified both WAIT=DEFER and a 
parameter for the keyword operand RET, code is generated both to 
load the return address into register l4 (RR) and to branch to the 
monitor via register 15 (RC). For all other cases a standard BALR 



instruction is generated. Finally, if WAIT=DEFER is not specified, 
the macro TMSWAIT is invoiced with the proper OP and RET parameters. 

5*5 TMSFREEM Macro 

The TMSFREEM macro tests to see that its parameter both exists 
and is a register designator. If both of these tests are passed, 
the code is generated to clear register 0 (RPO) and to load register 
1 (RPl) from the register specified. The TMSLINK macro is then 
invoiced to generate code that finds the entry point of the GETMAIN/ 
FREEMAIN routine, and the usual BALR instruction is generated to 
branch to it. 

5.6 TMSGETM Macro 

The TMSGETM macro first verifies the presence of its single 
parameter and then determines whether it is a register designator 
or a symbolic expression. A suitable LR or LA instruction is 
generated as needed. The macro TMSLINK is then invoked to generate 
code that finds the entry point in the monitor of the GETMAIN/ 
FREEMAIN routine, and the usual RALR instruction Is generated to 
branch to it. 

.5-7 TMSLINK Macro 

The TMSLINK macro employs the global binary variable &TMSRFB 
to determine if the user program is maintaining the FB pointer 
in register 11 (R9). It also employs the global character variable 
&TMSRCR to indicate which register (if any) xs being maintained 
by the user program as a pointer to the CR. 

The only parameter for TMSLINK is a name which corresponds 
to one of the names defined in the Communication Region DSECT. 

If the global character variable &TMSRCR indicates that a pointer 
to the CR is being maintained, code Is generated merely to load 
the required entry point address into register 15 (RC) from the 
CR . The macro is then exited. If the CR pointer is not being 
maintained, the global binary variable &TMSRFB is tested to see 
if the FB pointer is being maintained in register 11. If it is, 
code is generated both to obtain the CR pointer from the FB and 
to place it in register 15 (RC), assuming that a COPY FB state- 
ment has been encountered earlier in the assembly. Code is then 
generated to establish addressability to the CR via a USING 
statement, to load register 15 (RC) with the entry point address, 
and then to cancel the effect of the USING statement with a DROP 
statement . 

In the event that neither the FB pointer nor the CR pointer 
is being maintained by the user program, code is generated to load 
the address of the FB into register 15 (RC) from the first word 
of the area pointed to by regj ster 13 (RS). Addressability to the 
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FB is then established followed by code to load the C !R address 
into register 15, followed again by code to load the entry point 
address into register 15. Thus, regardless of which registers 
are "being maintained hy the user program, code is generated to 
insure that the requisite entry point address is left in register 
15 "by the time this macro exits. 

5.8 TMSOPEN Macro 

The TMSOPEN macro begins extensive checking of its operands 
first hy checking that the DSNAME operand exists and is less than 
or equal to eight characters in length. It then sets various flags 
based upon the RETURN, QUALIFY, and BUFFERS operands. At the 
same time a special output flag is set to indicate to the remainder 
of the macro whether WRITE operations will be acceptable for this 
data set. The FOR operand is then analyzed and four single-bit 
flags are set in patterns corresponding to their use in the standard 
0/S OPEN macro. The options recognized are INPUT, OUTPUT, UPDAT, 
INOUT, and OUTIN. 

The DSORG operand is then tested in a manner similar to its 
analysis in expanding the 0/S DCB macro instruction. It must 
both exist and be two or three characters in length. The first 
two characters are isolated and tested to see if they are either 
one of the four allowable TMS combinations or one of four further 
combinations, one of several single bit flags is set. These 
single bit flags will be used later to assemble the halfword 
PDSORG field in the expanded parameter list produced by the macro. 

As with DSORG, the MACRF operand has a set of permissable 
values which itself is a sub-set of values permissable in the 0/S 
DCB macro instruction. The analysis of this operand also is based 
upon the methodology used in the DCB macro. Since the MACRF 
operand may have several sub-parameters , an outer analysis loop 
is set up to analyze each sub-parameter at a time. The first 
character of each sub-parameter is isolated within this loop; this 
initial letter may have one of six values, only five of which are 
valid in TMS. If the initial letter is an E for EXCP , 20 bit 
flags are immediately set to a predetermined combination, and the 
MACRF operand analysis is finished. If the initial letter is P 
for PUT, the loop is exited without setting any flags for this 
particular sub-operand. If the initial character is R for READ 
or W for WRITE, the analysis continues by setting up an inner 
loop to analyze these remaining characters in the sub-operand 
considered to be qualifiers of the initial character. Each 
qualifier is isolated in turn and analyzed to see if it is one 
of the valid letters. If it is a valid letter, the settings of 
relevant DSORG flags are checked to see if the combination of the 
qualifier and the data set organization represents a valid 
specification. If it is valid, the proper bit flags are set, and 
the inner loop is repeated until all qualifiers have been exhausted. 
At this time the outer loop is repeated if any sub-operands remain. 



If analysis has been completed on all MACRF sub-operands , a 
particular bit pattern has been established in 20 bit flags. 

The third operand with a direct analog in the 0/S DCB 
macro is the OPTCD operand. As before, the analysis of this 
operand is a sub-set of the analysis used in the DCB macro. Each 
character of the operand is analyzed to see if it is one of 
severa p acceptable letters- If an acceptable letter if found, the 
bit flags set for DSORG are checked to see that the combination 
of the letter and the data set organization is a valid specifica- 
tion. For each valid combination, one of eight bit flags is set. 

The code generation portion for the macro begins, if 
necessary, with a BAL instruction branching around the in-line 
parameter list and loading the address of the parameter list into 
register 1 (RPl). The nine DSORG bit flags, followed by three 
binary zeros, followed by the four open option flags are assembled 
into a halfword binary bit pattern, and the corresponding, DC 
instruction is generated. Following this, another halfword binary 
bit pattern, consisting of the first l6 MACRF flags, is assembled, 
and a second DC is generated. The eight OFTCD binary bit flags next 
are assembled into a single byte DC. The DC for an A-type address 
constant of length three containing the address specified. as the 
SYNAD operand follows. At this point in the generation, if EXCP 
processing with appendages has been specified, the six DC instruc- 
tions for character constants, each of length two, are assembled 
to represent the various appendage specifications. Following either 
of these appendage parameters, or the EODAD address if the appendage 
specifications are not present, comes the DC for a binary halfword 
count of the number of characters in the DSNAME operand. This is 
followed by the DC for a variable length field containing the 
EBDCIC character representation of the DSNAME operand. At this 
point in the generation, a direct branch is taken to the linkage 
generation portion of the macro, which is sequence symbol ".LINK . 

Immediately following the above code comes the analysis of 
the second operand of the MF operand when it is specified for an 
execute form macro instruction. Verified as present, this second 
sub— operand is tested to see whether it is a register designator 
or a symbolic address. For a register designator, the proper LR 
instruction is generated to bring the parameter list address into 
register 1 (RPl); for a symbolic address an LA instruction is 
generated for the same purpose. The final portion of the genera- 
tion is the linkage to the monitor system OPEN routine. The 
macro TMSLINK is invoked to generate the code that will place the 
entry point of the TMSOPEN routine in register 15 (RC). The final 
instruction generated for standard or execute form macro expansions 
is the usual RA.LR instruction. 

5.9 TMSRETN Macro 

The TMSRETN macro employs a global character variable &TMSRMSA 
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to determine whether the save area produced by the corresponding 
TMSSAVE macro was local, remote, or not supplied at all. 

If the global variable indicates that the save area obtained 
was a remote save area, code is generated to place the current 
save address into register 1 (RPl), obtain the address of the 
previous save area from the second fullword of the current save 
area, put it in register 13 (RS), and invoke the TMSFREEM macro 
to free the core obtained for the remote save area. Control then 
passes to the common coding at the sequence symbol ".RESTORE". 

If it is determined that the save area involved is a local save 
area, the only unique code generated is that to obtain the address 
of the previous save area. If no save area at all is generated, 
control immediately passes to the common coding. The common 
coding generates code to zero the downward save area pointer in 
the third fullword of the previous save area, restore registers 
l4 (RR) through 12 (R3) from the previous save area, and return 
to the calling program via register l4 (RR). 

5-10 TMSSAVE Macro 

The TMSSAVE macro sets the global binary variable &TMSRFB 
to indicate to future macro instructions whether or not the problem 
programmer will maintain register 11 (R9) as a pointer to the FB. 

It sets the global character variable &TMSRMSA to show whether 
the save area obtained is a local save area, a remote save area, 
or non-existant . It sets the global character variable &TMSRCR to 
indicate which register, if any, the problem programmer guarantees 
to point to the CR. All three of these global variables play an 
important part in the expansion of most of the remaining macro 
instructions in the program. 

The first operation performed by the expansion of TMSSAVE is 
a test on the parameter of the SAINCR keyword operand to see if 
it exceeds 4023 bytes. The purpose of this test is to issue a 
warning message if the increment plus the 72 byte save area exceeds 
4095 bytes, thus indicating a possible requirement for an additional 
base register or registers. Following this test, code is generated 
to define the CSECT , to save the registers in the save area point- 
ed to by register 13 (RS) by means of a STM instruction,, to 
establish the permanent base register by means of an IK instruction, 
and to issue the USING instruction for the main base register. If 
RFB=N0NE is not coded, the global binary variable &TMSRFB is set 
to indicate that the FB pointer will be maintained. The USING 
instruction for the FB pointer then is generated. If a register 
has been specified to act as the CR pointer, the specification is 
stored in the global character variable &TMSRCR and, if necessary, 
an LR instruction to load the CR pointer register from register 10 
(r 8) is issued. A USING instruction for the CR pointer follows 
the LR instruction. 

The remainder of the macro obtains a save area If one is 




required. The global character variable &TMSRMSA is set to the 
letter ,T N ,T as a default, and if SA=NONE has been coded, the macro 
is exited at this point. If SA=REMOTE, the default option, has 
been coded, &TMSRMSA is set to the letter T, H ft , and one of two 
sequences of code is generated. If the sum of 72 and the value 
specified for SAINCR is less than or equal to 4095 9 the TMSGETM 
macro instruction is invoked with LV specified as a symbolic 
expression. However, when the amount of core to be obtained is 
greater than 4095 bytes , a halfword constant is generated in- 
line along with code to branch around this constant, load it into 
register 0 (RPO), and invoke the macro instruction TMSGETM LV= 
(KPO). Regardless of which form of code has been generated to 
obtain the remote save area, code is now generated both to clear 
the first 72 bytes of the save area and to load the pointer to 
the new save area into the register specified by the keyword 
operand RWORK. The macro then branches to the sequence symbol 
".CHAINSA", If SA=L0CAL has been specified, &TMSRMSA is set to 
the letter T, L n and an l8-fullword save area is generated in-line 
with code both to branch around it and put its address into the 
register specified in the keyword operand RWORK. For both local 
and remote save areas, code is then generated to move the FB 
pointer from the first word of the old save area to the first 
word of the new save area and to link the two save areas in 
standard 0/S fashion, losing the register specified by the keyword 
operand RWORK as a work register. 

5 . 11 TMSWAIT Macro 

The TMSWAIT macro uses the global binary variable &TMSRFB to 
determine whether or not the problem programmer is maintaining 
register 11 (R9) as a pointer to the FB. 

The macro first tests for the special case where ECB=FBECB 
has been coded and the FB pointer is not being maintained by the 
problem programmer. If both these conditions exist, code is 
generated to obtain the FB. pointer from the first word of the 
current save area and establish addressability to the FB by means 
of a USING instruction. An LA instruction to load register 1 
(RPl) with the ECB address is then generated, followed by a DROP 
instruction to terminate FB addressability . If this special case 
does not exist, the only instruction generated is the LA instruc- 
tion to load register 1 with the ECB address. 

The TMSLINK macro is invoked to generate the necessary code 
to locate the WAIT routine entry point in the monitor. If a 
return address has been supplied by use of the RET keyword operand, 
and 0P=READ has not been coded, an LA instruction is generated to 
load register l4 (KR) with the return address, followed by a BR 
instruction to branch to the WAIT routine’s entry point. In all 
other cases , the usual BALR instruction is generated. If 0P=READ 
has not been coded, the macro is exited at this point. If it has, 
an SR instruction is generated to clear register 1. If the problem 
programmer is maintaining the FB pointer, code is generated both 




to calculate the start of text and length of text in the buffer and 
to leave these in the proper registers. This code consists of an 
IC instruction to place the text offset from FBBUFOFF into register 
1; an L instruction followed by an N instruction to obtain the 
buffer address from FBBUFPTR and leave it in register 0; an AB 
insti iction to add the buffer address in register 0 to the offset 
in register 1, leaving the resulting pointer to the start of text 
in register 1; and an LH instruction to put the lengbh of text from 
FBLMLNTH into register 0. If the problem programmer is not main- 
taining the FB pointer in register 11, the same code is generated 
first, preceded by both an L instruction and a USING instruction 
to obtain the FB address and to establish addressability, and then 
followed by a DROP instruction to end addressability. 
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APPENDIX 1: TMS MODULE NAMES AND ENTRY POINTS 



MODULE 



ENTRY POINTS 



TMSHSKP 

TMSBLOCK 

TMSPJOB 

TMSPLOAD 

TMSBEGIN 

TMSCNSL 

TMSCSIO 



TMSWAIT 

TMSTREND 

TMSGMFM 

TMSOPEN 

TMSCLOSE 

TMSPURGE 

TMSGTSLE 

TMSDEBUG 



TMSHSKP 

TMSBLOCK 

TMSBLGTH 

IMSLSTFB 

TMSPJOB 

TMSPLOAD 

TMSBEGIN 

TM3CRADR 

TMSSYSSV 

TMSCNSL 

TMSREADY 

TMSCSIO 

TMSWRDEQ 

TMSRDRST 

TMSCSIOR 

TMSWAIT 

TMSDWAIT 

TMSQWAIT 

TMSTREND 

TMSCHEND 

TMSGMFM 

TMSOPEN 

TMSCLOSE 

TMSPCLOS 

TMSPURGE 

TMSGTSLE 

TMSDEBUG 
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APPENDIX 2A: COMMUNICATION REGION — ' CR ' 



OFFSET 

* 



* 

* 

* 

,y- 

* 

* 



The general communication region is located in the 
resident monitor code. A pointer to it is located 
in each function block as 1 FBCR*. 

Aligned on Fullvord Boundary 



000000 CR 
* 



Dsect 



000000 


CRWAIT 


DS 


A 


Address 


of 


EP ' 


TMSWAIT ' 


OOOOOU 


CRCSIO 


DS 


A 


Address 


of 


EP ' 


TMSCSIO 1 


000008 


CRPURGE 


DS 


A 


Address 


of 


EP ' 


TMSPURGE ' 


oooooc 


CRLOAD 


DS 


A 


Address 


of 


EP ' 


TMSPLOAD ' 


000010 


CRGMFM 


DS 


A 


Addres s 


of 


EP ' 


TMSGMFM' 


00001U 


CRSNAP 


DS 


A 


Address 


of 


EP ' 


TMS SNAP ' 


000018 


CROPEN 


DS 


A 


Addres s 


of 


EP ' 


TMSOPEN' 


00001C 


CRCLOSE 


DS 


A 


Address 


of 


EP ' 


TMSCLOSE 1 


000020 


CRWL 


DS 


A 


Pointer 


to 


WAIT List 


00002U 


CRWLLAST 


DS 


A 


Pointer 


to 


Current Last Entry 


000028 


CRECB 

* 


DS 


A 


CR Dummy ECB 






CRWRITE 


EQU 


X * 20 T 


Line Newly 


Available for WRITE 




CRERPOLL 

* 


EQU 


X'10* 


Line Available 


for Poll RESTART 


00002C 


CRIND 


DS 


XL1 


CR Indicators 





* 



CRCEERR EQU X f 80 T 

* 



Error in Channel End Routine 



00002D 


CRABCODE 


DS 


XL1 


00002E 


CRWLX 


DS 


H 


000030 


CRLIBDCE 


DS 


A 


00003U 


CRSNPDCB 


DS 


A 


000038 


CRLOGDCB 


DS 


A 


00003 c 


CRFBCHN 


DS 


A 


0000U0 


CRQFLAGS 

* 


DS 


0XL1 




CRQEND 


EQU 


X* 80 T 




CRQWRITE 


EQU 


X'UO' 




CRQRPOLL 


EQU 


X 1 20 T 




CRQSNAP 


EQU 


X'10' 




CRQPLOAD 

* 


EQU 


x'o8' 


0000U0 


CR QUEUE 


DS 


A 


0O00UU 


CRPICA 


DS 


F 


0000U8 


CRGISLE 


DS 


A 


000050 


CREND 


DS 


OD 




CRLENGTH 


FQU 

COPY 


CREND- CR 
FB 



Abnormal End Code 

Offset to WAIT List Extension 

Address of Program Library DCB 

Address of Snap DCB 

Address of System Log DCB 

Start of FB Chain 

Current Needs of Queued FB f s 

No FB ? s Queued at This Time 
1 or More Queued for WRITE 
1 or More Queued for Poll RESTART 
1 or More Queued for SNAPSHOT 
1 or More Queued for Program LOAD 

PTR to Queue of FB T s 

Save Area for PICA 

Addr e s s o f EP 1 TMS GTS LE 1 

End of Communication Region 

Length of Communication Region 
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Cl' FB TDECB 



GENERAL COMMUNICATION REGION — ’CR’ 



0 (0) 


CRWAIT 


Address of EP T TMSWAIT T 


4 (4) 


CRCSIO 


Address of EP T TMSCS10 T __ 


8 (8) 


CRPURGE 


Address of EP f TMSPURGE* 


12(C) 


CRPLOAD 


Address of EP T TMSPLOAD T . . 


I6(10) 


CRGMFM 


Address of EP ’ TMSGMFM 1 


20 (l4) 


CRSNAP 


Address of EP * TMSSNAP * 


24(18) 


CROPEN 


Address of EP ’ TMSOPEN ’ _ 


28(1C) 


CR CLOSE 


Address of EP T TMS CLOSE 1 


32(20) 


CRWL 




Address of WAIT List — ■ 


36(24) 


CRWLLAS7 


__ Address of Last Entry 


1+0(28) 


CRECB 




Communication Regd 


on Event Control Block 


1+1+ (2C) CRIND 


45 CRABCODE 


46 (2E) CRWLX 


CR Indicators 


Abnormal End Code 


Offset to WAIT List Extension 


1+8(30) 


CRLIBDCB 




Address of Program 


Lihrarv DCB 


52(31+) 


CRSNPDCB 


Address of Snan DCB 


56(38) 


CRLOGDCB 


Address of System Log DCB 


60 ( 3C ) 


CRFBCHN 




Start of FB Chain 




61+ (1+0) CRQFLAGS 




65(41) CRQUEUE 


Queued FB Needs 




PTR to Queue of FB's 


68(44) 


CRPIE 






Save Area for PIE 




72(48) 


CRGTSLE 




Address of EP 1 TMSGTSLE ’ 
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GENERAL COMMUNICATIONS REGION — 'CR' 



OFFSET 


BYTES & 
ALIGNMENT 


FIELD 

NAME 


HEX. 

DIG. 


FIELD DESCRIPTION r CONTENTS, MEANING^ 


0 


(0) 


4 


CRWAIT 




Address of Entry Point for TMSWAIT Module 


u 


(k) 


4 


CRCSIO 




Address of Entry Point for TMSCSIO Module 


8 


( 8 ) 


4 


CRPURGE 




Address of Entry Point for TMSPURGE Module 


12 


(c) 


h 


CRPLOAD 




Address of Entry Point for TMSPLOAD Module 


16 


( 10 ) 


h 


CRGMFM 




Address of Entry Point for TMSGMFM Module 


20 


(l4) 


h 


CRSNAP 




Address of Entry Point for TMSSNAP Module 












(not used at this time) 


2h 


( 18 ) 


h 


CROPEN 




Address of Entry Point for TMSOPEN Module 


28 


(1C) 


k 


CRCLOSE 




Address of Entry Point for TMSCLOSE Module 


32 


( 20 ) 


k 


CRWL 




Address of the WAIT List 


36 


(24) 


k 


CRWLLAST 




Address of the Last Current Entry on WAIT List 


40 


( 28 ) 


k 


CRECB 




Communication Region Dummy Event Control Block 








XX. . xxxx 

. . .1 .... 




(Reserved Bits) 

Line Newly Available for WRITE 
Line Available for Polling RESTART 


44 


(2C) 


1 


CRIND 




CR Indicators 








. XXX xxxx 
1 




(Reserved Bits) 

Error in Channel End Routine 


45 


(2D) 


. 1 


CRABCODE 




Abnormal End Code 










28 


Unsuccessful Polling Halt 










29 


Buffer Unavailable for WRITE Initialization 










2 A . 


Start of WRITE Unsuccessful (CSIO) 










2B 


Buffer Unavailable for Input 










2C 


Error in Channel was not Timeout, Lost Data, 












or Data Check 










2D 


RESTART Parameter Set Already Exists (CSIO) 










32 


Invalid Terminal List Offset 










33 


Both READ and WRITE Operations Specified 










3k 


Neither READ or WRITE Operations Specified 










35 


Invalid Buffer Flags at READ Completion 










37 


Active Polling Count Invalid at READ 



Completion 
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GENERAL COMMUNICATIONS REGION — f CR f 



BYTES & FIELD HEX. 

OFFSET ALIGNMENT NAME DIG. FIELD DESCRIPTION, CONTENTS, MEANING 

38 Improper Flags in DECUFLGS Field of TDECB 

39 Improper Buffer Flags at End of WRITE 
3A Channel Error Processing for CE * DE, UC 

Redundant 

3B Error is not Channel End, Device End, Unit 
Check 

3C RESTART Parameter Set Already Exists (TREND) 
3D Start of WRITE Unsuccessful (TREND) 

3E Start of READ Unsuccessful (TREND) 

FF I/O Error Recovery Failure 



46 (2E) 


2 


CRWLX 


Offset to WAIT List Extension 


48 (30) 


4 


CRLIBDCB 


Address of Program Library DCB 


52 (34) 


4 


CRSNPDCB 


Address of Snap DCB 


56 (38) 


4 


CRLOGDCB 


Address of System Log DCB 


60 ( 3C ) 


4 


CRFBCHN 


Start of FB Chain 


64 ( 4o ) 


1 


CRQFLAGS 


Current 






XXX 

1 

«1«« .... 

. . 1 « .... 


(Reserved Bits) 

No. FB f s Queued at This Time 
1 or More Queued for WRITE 
1 or More Queued for Polling RESTART 
1 or More Queued for Snapshot 
1 or More Queued for Program Load 


65 (41) 


. 1 


CRQUEUE 


Address of Queue of FB ? s 


68 (44) 


4 


CRPIE 


Save Area for PIE 


72 (48) 


4 


CHGTSLE 


Address of Entry Point for TMSGTSLE Module 
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APPENDIX 2B : FUNCTION BLOCK — 'FB' 



OFFSET 


* 










* 


The function 


control Block exists for each operating 




* 


terminal and 


contains control information, work areas 




* 


etc . 








* 

* 


Aligned on Fullvord Boundary 


000000 


FB 

% 


DSECT 






000000 


FBSAVE 


DS 


i6f 


Special Function Save Area 


ooooUo 


FBECB 


DS 


F 


Event Control Block 


ooooUU 


FBFDLAGS 

* 


DS 


0XL1 


FB Flags 




FBXMIERR 


EQU 


X'8o' 


Transmission Error 




FBDSCNCT 


EQU 


x'4o' 


Disconnect 




FBBEBUG 


EQU 


X' 20 ' 


Debugging on Terminal 


oooo44 


FBCB 


DS 


A 


Address of Communications Region 


oooo4b 


FBEFLAG 

* 


DS 


0XL1 






FBEPJOB 


EQU 


X'Ol’ 


Last Entry Thru PJOB 




FBEPJOBP 


EQU 


X' 02 ' 


Last Entry Thru Purged in PJOB 




FBEPLOAD 


EQU 


X'03' 


Last Entry Thru PLOAD 




FBECNSL 


EQU 


x'o4' 


Last Entry Thru CNSL 




FBEREADY 


EQU 


X’05' 


Last Entry Thru READY 




FBECSIO 


EQU 


x’o6' 


Last Entry Thru CSIO 




FBEWRDEQ 


EQU 


x'OT' 


Last Entry Thru WRDEQ 




FBERDRST 


EQU 


x’o8' 


Last Entry Thru RDRST 




FBLJSIOR 


EQU 


X'09' 


Last Entry Thru CSIOR 




FBEWAIT 


EQU 


X'lO' 


Last Entry Thru WAIT 




FBEBWAIT 


EQU 


X'll' 


Last Entry Thru DWAIT 




FBEQWAIT 


EQU 


X’ 12 ' 


Last Entry Thru QWAIT 




FBETREND 


EQU 


X’13' 


Last Entry Thru TREND 




FBEGMFM 


EQU 


X'l4' 


Last Entry Thru GMFM 




FBEOPEN 


EQU 


X’ 15 ' 


Last Entry Thru OPEN 




FBE CLOSE 


EQU 


X'i6' 


Last Entry Thru CLOSE 




FBEPCLOS 


EQU 


x' 17' 


Last Entry Thru PCLOS 




FBEPURGE 


EQU 


X'i8' 


Last Entry Thru PURGE 




FBEDEBUG 

* 


EQU 


X' 19 ' 


Last Entry Thru DEBUG 


000048 


FB CHAIN 


DS 


A 


Pointer to Next FB 


oooo4c 


FBRLN 


DS 


0XL1 


Relative Line No, for This Line 


oooo4c 


FBTCHAIN 


DS 


A 


Next FB Chained for This Line 


000050 


FBQFLAGS 

* 


DS 


0XL1 


Reason for Which FB is Queued 




FBQEND 


EQU 


x'8o' 


Last FB on Queue 




FBQWRITE 


EQU 


x' 4o' 


FB Queued for WRITE to Terminal 




FBQRPOLL 


EQU 


X' 20 ' 


FB Queued for READ Poll RESTART 




FBQSNAP 


EQU 


X'lO' 


FB Queued for SNAPSHOT Routine 




FBQPLOAD 


EQU 


x'o8' 


FB Queued for Nev Program LOAD 


000050 


FBQUEUE 


DS 


A 


PTR to Next Queued FB 



o 

ERJC 
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APPENDIX 2B (CONT. ) 



OFFSET 

000054 


FBBLKCHJ-I 


DS 


A 


Start of User Storage Block Chain 


000058 


FBDCBCHN 


DS 


A 


Start of User DCB Chain 


00005c 


FBTLOFF 


DS 


H 


Terminal List Offset 


00005E 


FBPOLL 


DS 


H 


Polling Characters for Console 


000060 


FBRWOP 

* 


DS 


0XL1 


READ/WRITE Opcode for Terminal 




FBRWRITE 


EQU 


X'8o' 


Bit to Indicate WRITE 




FBRWPE 


EQU 


X'40' 


Bit to Indicate PRE-ERASE 




FBRWCRAW 


EQU 


X' 20 ' 


Bit to Indicate CR After WRITE 




FBRWEDIT 


EQU 


X ! 08 ' 


Bit to Indicate Edit Before WRITE 




FBRWNLEW 


EQU 


x'o 4 ' 


Bit to Indicate NL Before WRITE 




FBRWLREG 


EQU 


X' 02 ’ 


Bit to Indicate Length in RPO 




FBRWRWRT 


EQU 


X* 01 * 


Bit to Indicate REWRITE 


000060 


FBDECB 


DS 


A 


DECB for Line Associated With FB 


oooo 64 


FBBUFOFF 


DS 


0XL1 


Offset to Text in Buffer 


oooo 64 


FBBUFPTR 


DS 


A 


PTR to Buffer Attached to FB 


000068 


FBWFLAGS 


DS 


0XL1 


Working Flags 


000068 


FBWF 

FBWRKPTR 


EQU 

DS 


X' 80 ' 
A 


Working Pointer 


00006c 


FBLCOUNT 


DS 


H 


Current Line Count 


00006E 


FBCLLGTH 


DS 


H 


Length of Current Line 


000070 


FBLMLNTH 


DS 


F 


Length of Previous Message 


000072 


FBTERMNO 


DS 


' l»2 


Terminal Number in EBCDIC 


000074 


FBNAME 


DS 


CL 4 


Name of Current User 


000078 


FBPNAME 


DS 


CL 8 


Name of Current User Program 


000080 


FBEND 


DS 


OF 


End of Function Block 




FBLENGTH 


DS 


OXL ( FBEND -FBSAVE) 


Length of Function Block 



±zi 



FUNCTION CONTROL BLOCK — 'FB' 



0 (0) FBSAVE 

Save Area for Users Register 

60 (3C) _ 


64 ( 40 ) FBECB 

Eventt^ontrotJ3lQek 


68 (44) FBFLAGS 
FB Flags 


FBCR 

Address of CR 


72 (48) FB CHAIN 

Pointer to Next FB 


76 ( 4C ) FBRLN 
Relative Line No. 


FBTCHAIN 

Next FB Chained for Their Line 


80 ( 50 ) FBQFLAGS 
Reason FB is Queued 


FBQUEUE 

Pointer to Next Oueued FB 


84 (54) FBBLKCHN 

Start of User Storage Block Chain 


88 (58) FBDCBCHN 

Start of User DCB Chain 


92 (5C) FBT 

.. - ... Terminal L 


LOFF 

.1 s t Offset 


94 (5E) FB Poll 

Pnll-inc- Characters 


96 (6o ) FBRWOP 
READ /WRITE Opcode 


FBDECB 

HECB for Line Associated with This FB 


100 (64) FBBUFOFF 
Offset to Text 


FBBUFPTR 

Address of Buffer Attached to This FB 


10 4 (68) FBWFLAGS 
Working Flags 


FBWRUPTR 
Working Pointer 


10 8 (6c) fbblcount 

Current Lirx= Count 


110 (6E) fbcllgth 

Length of Curren-h Line 


112 ( 70 ) FBLMLNTH 

Length of Previous Message 


114 (72) FBTERMNO 

Terminal Numher- 


116 (74) FBNAME 

Name of Current User 


120 ( 78 ) FBPNAME 

Name of Current User Program 



O 

ERIC 




V 



- 127 - 



CONTROL BLOCK— 'FB' 



BYTES AND 
OFFSET ALIGNMENT 



0 ( 0 ) 
64 (ho) 
68 (44) 



68 (44) 
72 (48) 
76 (4C) 
76 (4c) 
8o (50) 



6h 

k 

1 



k 

k 

1 

k 

1 



field description, contend s v j^eanti^- 

Save Area for TMS Functions 

Event Control Block 

Function Block Flags: 

(Reserved Bits) 

'l, • % x * * . FBXMTERR - Transmission Erfof 
» FBDSCNCT <•- Disconnect 
> „ * • * . FBDEBUG - Debugging of TerDtln^l 

Address of Communications Region 

Pointer to Next FB 

Relative Line Number for This Line 

Nexrt FB Chained for This Line 

Reason for Which FB is Que^ti: 

' . * , (Reserved Bits) 

'l. FBQUEND - Last FB on Queue 

FBqWRITF - FB Queued for WRITE to Terminal 
FBQRPOLL - FB Queued for REAP Polling Restart 
FBqSNAP - FB Queued for Snapshot 
FBqPLOAD - FB Queued for Program Load 



8o 


(50) 


4 




Pointer to Next Queued FB 


CO 

■pr* 


(54) 


4 




Start of User Stor age BlocK Chain 


CO 

CO 


\J1 

CO 


4 


^P^Qhn 


Start of User DCB Chain 


92 


(5C) 


2 




Offset in Terminal List to Entry* for This FB 
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FUNCTION CONTROL BLOCK — ’FB’ 



BYTES & FIELD 



OFFSET 


alignment 


NAME 


FIELD DESCRIPTION, CONTENTS, MEANING 


9 b 


( 5 E) 




2 


FBP 0 LL 


Polling Characters for This FB 


96 


(6o) 


i 




FBRWOP 


READ /WRITE Opcode 


96 ' 


(6o) 


U 




FBDECB 


DECB for the Line Associated With This FB 


100 


(6U) 


1 




FBBUFOFF 


Offset to Beginning of Text in Input Buffer 


100 


( 6 k) 


u 




FBBUFPTR 


Address of Buffer Attached to This FB 


o 

H 


(68) 


1 




FBWFLAGS 


Working Flags 


o 

H 


(68) 


h 




FBWRKPTR 


Working Pointer 


108 


(6c) 


2 




FBBLCOUNT 


Current Line Count 


no 


(6e) 


• • 


2 


FBCLLGTH 


Length of Current Line 


112 


( 70 ) 


2 




FBLMLNTH 


Length of Previous Message 


nk 


( 72 ) 


» • 


2 


FBTERMNO 


Terminal Number in EBCDIC 


116 


( 7*0 


k 




FBNAME 


Name of Current User 


120 


(78) 


8 




FBPNAME 


Name of Current User Program 



o 
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APPENDIX 2 C : 



TELEPROCESSING DATA EVENT CONTROL BLOCK (TDECB) 



OFFSET 





* 


The data event 


control Block for teleprocessing via 




* 


BTAM consists 


of bO Bytes defined By IBM plus user- 




* 


defined 


fields 


defined for the TMS system. 




* 

# 


Aligned 


on Fullvord Boundary 


000000 


TDECB 


DSECT 






000000 


DECSDECB 


DS 


F 


Standard Event Control 


oooooU 


DECTYPE 


DS 


H 


Block Operation Type 




# 


Standard BTAM Optype Codes (Second Byte) 




DEC RTI 


EQU 


X'Ol* 


READ Initial 




DECWTI 


EQU 


X 1 02 ! 


WRITE Initial 




DECWTIR 


EQU 


X ! 82 1 


WRITE Initial With Reset 




DECRTT 


EQU 


X'OB' 


READ Continue 




DECRTP 


EQU 


X ! OT 1 


READ Repeat 




DECWTA 


EQU 


X f 08 1 


WRITE POSITIVE ACKNOWLEDGE 




DECWTSR 

* 


EQU 


X 1 8E' 


WRITE Erase With Reset 


000006 


DECLNGTH 


DS 


H 


Area Length 


000008 


DECONLTT 


DS 


0 CL 1 


Reserved For On-Line Terminal Test 


000008 


DECDCBAD 


DS 


A 


Address of DCB 


oooooc 


DECAREA 


DS 


A 


Address of Area 


000010 


DECSENSO 

* 


DS 


C 


1 st Sense Byte 




DECSCMRJ 


EQU 


X ! 80 1 


Command Reject 




—DECS INTV 


EQU 


X ! tO' 


Intervention Required 




DECSBOCK 


EQU 


X ! 20 1 


Bus out Parity Check 




DECSEQCK 


EQU 


X'lO* 


Equipment Check 




DECSDTCK 


EQU 


X ! 08 1 


Data Check 




DECS OVEN 


EQU 


x’oU 1 


Overrun 




DECSLOST 


EQU 


X ! 02 1 


Lost Data 




DEC STOUT 
# 


EQU 


X f 01 ' 


Timeout 


000011 


DECSENS 1 


DS 


c 


2 nd Sense Byte 


000012 


DEC COUNT 


DS 


H 


Residual Count 


ooooiU 


DEC CMC OD 


DS 


0 CL 1 


Command Code 


ooooiU 


DECENTRY 


DS 


A 


Address of Terminal List 


000018 


DEC FLAGS 


DS 


C 


Status Flags 




DECFNEGR 


EQU 


X'oU' 


Negative Response to Polling 


000019 


DEC RLN 


DS 


C 


Relative Line NumBer 


00001 A 


DECRESPN 


DS 


H 


Response Fields 


00001 C 


DECTPCOD 


DS 


H 


Teleprocessing Opcode 


00001 D 


DECERRST 


DS 


.■i 


Error Status 


00001 E 


DECCSWST 


DS 


c 


CSW Status 



3 
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APPENDIX 2C : TDECB ( CONT. ) 



OFFSET 





DECCSWCE 


EQU 


X f 08’ 




DECCSWDE 


EQU 


X f 04 1 




DECCSWUC 


EQU 


X f 02 1 




DECCSWUE 


EQU 


x f 01 ' 




DECCSWIL 


EQU 


X t h0’ 


000020 


DECADRPT 


DS 


A 


000024 


DECP0LPT 

* 


DS 


A 




* 

* 


Fields 


Specific 


000028 


DECFBCHN 


DS 


A 


00002C 


DECAP CNT 


DS 


H 


00002E 


DECWWCNT 


DS 


H 


000030 


DECT TYPE 
* 


DS 


0XL1 




DEC CRT 


EQU 


X’8o r 




DECTYPEW 


EQU 


x f 4o' 




DECMULTI 


EQU 


x^o 1 




DECSEPLF 

* 


EQU 


X f 10 1 


000030 


DECTTIN 


DS 


A 


000034 


DECUFLGS 

s- 


DS 


0XL1 




DECUFRIP 


EQU 


x'So 1 




DECUFWIP 


EQU 


x f 4o f 




DECUFPIN 


EQU 


X f 20 f 




DECUFWTW 


EQU 


X’10’ 




DECUFPRS 


EQU 


X f 08 ’ 




DECUFACK 


EQU 


x f oU f 


000034 


DEC TT OUT 


DS 


A 


000038 


DECCPNUL 


DS 


0XL1 


000038 


DECTTLIN 


DS 


A 


00003C 


DECRSAVE 


DS 


CL 11 


oooo47 


DECCPLIN 


DS 


XL1 


oooo48 


DECMAXNL 


DS 


0XL1 


oooo48 


DECTLIST 


DS 


A 



Status Flag — Channel End 
Status Flag— Device End 
Status Flag — Unit Check 
Status Flag — Unit Exception 
Status Flag — Incorrect Length 

Address of Current Addressing Entry 
Address of Current Polling Entry 

to TMS 

PTR to Chain of FB’s for Line 
Active Polling Count 
Waiting-to-Write Count 
Terminal Type 

Bit to Indicate CRT Display- 
Bit to Indicate Typewriter 
Bit to Indicate Shared Line 
Separate Line Feed Required 

Address of Inbound Translate Table 
TMS Flags 

READ Polling in Progress 
Writing in Progress 
Polling Interrupted to Write 
Another Terminal Waiting to Write 
Polling RESET in Progress 
POSITIVE ACKNOWLEDGMENT Needed 

Address of Outbound Translate Table 
Characters Per Null for CR 
Address of Inbound L/U Translate 
Table 

Save Area for READ Parameters 
Characters Positions Per Line 
Maximum Number of Lines on Screen 
Address of Terminal List 
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DATA EVENT CONTROL BLOCK FOR TELEPROCESSING — ' TDECB' 



0 (G) 



DECS DECS 

Event Control Block 



4 (4) 



8 (8) DECONLTT 
(Reserved) 



DECTYPE 
Operation Type 



6 ( 6 ) 



DECLNGTH 
Area Length 



DEC DC BAD 
Address of DCB 



12 (C) 



DECADE A 

Address of Area 



16 (10) DECSENS0 IT (11) DEC SENS 1 
1st Sensp Bvtel 2nd Sense Bvte 



18 (12) 



DECCOUNT 
Residual Count 



20 (l4) DECCMCOD 
Command Code 



24 ( 18) DECFLAGS 
Status Flags 



DECENTRY 

Address of Terminal Lis ii. 



25 (19) DECRLN 
Relative Line No- 



26 (1A) DECRESPN 

Addressing Response Field 



28 (1C) DECTPCOD 
Operation 
32 (20) 



29 (ID) DECERRST 
I/O ERROR Status 



30 (IE) 



DECCSWST 
CSW Status 



36 (24) 



DECADRPT 

Ad dress of Current Addressing Entry 



DECPOLPT 

Address of Current Polling Entry 



UO (28) 



kk ( 2C ) 



DECAPCNT 

Active Polling Count 



DECFBCHN 

Point er to Chain of FB 
46 ( 2E ) 



DECWWCNT 

Waiting to Write Count 



48 (30) DEC TTYPE, DECTTIN 

Terminal Tyne- Address of Inbound Translate Table 



52 (34) DECUFLGS, DECTTOUT 

_ TMS Flags. Address of Outbound Translate Table 



56 (38) DECCPNUL, DECTTLIN 

Characters /Null for CR. Address of Inbound L/U Translate Table 

60 (3C) DECRSAVE 

Save Area for READ Parameters 



71 (47) DSCCPLIN 
Posit-i one /T,i tie 



72 (48) DECMAXNL , DECTLIST 

Maximum Number Lines /Screen , Address of Terminal List 
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DATA EVENT CONTROL BLOCK TOR TELEPROCESSING— 'TDECB 1 



OFFSET 



BYTES & 
ALIGNMENT 



0 ( 0 ) 4 

4 (4) 2 



IT (11) 

18 (12) 

20 (l4) 

21 (15) 

2 k (18) 

25 (19) 

2 6 (LA) 

28 (1C) 

29 (ID) 



1 

. 3 

1 



1 

. 1 



FIELD 

NAME 

D1CSDECB 

DECTYPE 



6 


(6) 


, . 2 


DECLNGTH 


8 


(8) 


1 


DEC0NLTT 


9 


(9) 


. 3 


DECDCBAD 


12 


(C) 


k 


DEC ARE A 


l6 


(10) 


1 


DECSENS0 








1 • * * * . * < 

» 1 • • • . ■ i 



BECSENSl 
DEC COUNT 



DECCMCOD 
DE GENTRY 
DECFLAGS 
xxxx x.xx 

DECRLN 

DECRESPN 

DECTPCOD 

DECERRST 



• * * * 
« * • i 



1. . . 

. 1 . . 

• * 1 * t t * i 

* . .X .XXX 

* * . m 1 ... 



HEX, 

DIG. 



01 

02 

82 

03 

07 

08 
8e 



FIELD DES CRimON^ CQNTMIS^ MRMIJKL - 

Event Control Block 

Operation Type 

BECRT1 - READ Initial 

BE0WT1 - WRITE Initial 

EECWT1K - WRITE Initial with Reset 

- READ Continue 

- READ Repeat 

DECWTA - WRITE POSITIVE ACKNOWLEDGE 
DECWTSR - WRITE Erase with Reset 

Length of Buffer or Message Area 

Reserved for On-Line Terminal Test 

Address of Associated DOB 

Address of Buffer or Message Area 

First Sense Byte 

DECSCMRJ - Command Reject 
DECS INTV - Intervention Required 
BR'OSROK - Bus out Parity Cheek 
DECSEQCK - Equipment Cheek 
DECSBTCK ~ Data Check 
DECSOVRN — Overrun 
DEC8L0ST - Last Data 
DECSTOUT - Timeout 

Second Sense Byte (Reserved) 

Residual Count From CSW for Last CCW 

Executed 

Command for Which Error Occurred 
Address of the Terminal List 
Status Flags 
(Reserved Bits) 

DECFNEGR - Negative Response to Polling 

Relative Line Number 

Addressing Response Field 

Teleprocessing Operation Code 

I/O ERROR Status Flags 

SI0 Resulted in a Condition Code of 3 

Undefined Error Condition 

I/O ERROR in Error Running Routine 

(Reserved Bits) 

Disable Issued to a Switched- Connected Line 



O 

ERIC 
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DATA EVENT CONTROL BLOCK FOR TELEPROCESSING — ’ TDECB 



OFFSET 



BYTES & 
ALIGNMENT 



FIELD 

NAME 



DIG, 



FIELD DESCRIPTION, CONTENTS, MEANING 



30 


(IE) 


* 


• 


2 


BECC8WST 


CSW Status 




32 


(20) 


4 






+ DECADRPT 


Address of Current Addressing Entry* 




36 


(24) 


4 






DECPOIPT 


Address of Current. Polling Entry 




ko 


(28) 


4 






DECFBCHN 


Pointer to Chain of FB f s for Line 




44 


(2C) 


2 






DECAP CNT 


Act! ire Polling Count 




46 


(2E) 


w 


, 


2 


DEC WONT 


Waiting to Write Count 




CO 


(30) 


1 






DECTTYFE 3 
















DECTTIN 


Terminal Type 




1+9 


(31) 


.. 


3 




DECTTIN 


Address of Inbound late Table 




52 


(34) 


1 






DECUFLGS , 
















BECTTOUT 


TMS Flags 














1. * ^ t 4 


DECUFHIP - READ Polling in Progress 














. 1 


DECUFWlP - Writing in Progress 














. ,1 


DFCIJFPTrN - Polling Interrupted to Write 














. 


DECUFWTW - Another Terminal Waiting 
to Write 














* * . , 1, . . 


DECUFPHS - Polling RESET in Progress^ 














1 # # 


DECUFACE - POSITIVE ACSOTOWLEDSE- Ifesded 














* # * XX 


( Reserved Bits) 




53 


(35) 


. 


3 




BECTTOUT 


Address of Outbound Translate Table 




56 


(38) 


1 






DECCPNUL , 
















BECTTLIN 


Characters per Null for CB 




57 


(39) 


. 


3 






Address of Inbound L/U Translate Table 




60 


( 30) 


11 




DECRSAVE 


Saire Area for READ' Parameters 




71 


(47) 


t 


* 




BECCPLXN 


Character Position per Line 




72 


(48) 


1 






DECMAXNL 3 




i 












BEGTLXST 


Maximum Number of Lines per Screen 




73 


(49) 


* 


3 




DECTLTST 


Address of Terminal List 


4 



o 
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APPENDIX 3 : LOAD MODULE ELEMENTS 



TMB i & divided into two load modules 5 each of which Is comprised of 
multiple object modules of control sections. The TMS load modules 
are made up as follows : 






INCLUDED OBJECT MODULES 



TMSHSKP TMSHSKP 

TMSBLOCK 



TMSEXEC 



TMSPJOB 

TMSPLOAB 

TMSBEGIN 

TMSCNSL 

TM5CSX0 

TM5WAXT 

IMS TREND 

TMBGMPM 

TMSOPEN 

TMS' CLOSE 

TMSPURGE 

EM5EEBUG 



O 
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APPENDIX If; STANDARD LIST OF I/O MODULES 



B3AM MODULES: 


IGGQ19SA 


BBAM 


IGGG198B 


Bsm 


BDAM MODULES: 


IGG019KA 


BDAM 


IGG019KC 


BDAM 


IGG019KE 


BDAM 


IGG019KI 


BDAM 


IGG019KK 


BDAM 


IGG019KM 


BDAM 


IGG019K0 


BDAM 


IGG019KS 


BDAM 


IGG019KU 


BDAM 


IGG019KW 


BDAM 


IGG019KY 


BDAM 


IGG0X9LA 


BDAM 


IGG019LC 


BDAM 


IGG019LI 


BDAM 


BTAM MODULES: 


IGG019MA 


BTAM 


XGGQ19MB 


BTAM 


IGG019M3 


BTAM 



READ/WRITE MODULE ( 384 BYTES) 

CHECK MODULE (96 BYTES - MODIFIED) 



FOUNDATION MODULE (l48Q BYTES) 

RELATIVE TRACK CONVERSION MODULE (280 BYTES) 
RELATIVE BLOCK CONVERSION MODULE ( 30U BYTES) 
CHANNEL PGM FOR KEY SEARCH (152 BYTES) 
CHANNEL PGM FOR ID SEARCH (176 BYTES) 

WRITE ADD FORMAT U OR V (581+ BYTES) 

WRITE ADD FORMAT F (264 BYTES) 

START I/O APPENDAGE (64 BYTES) 

CHANNEL END APPENDAGE (132 BYTES) 

KEY EXTENDED SEARCH (200 BYTES) 

SELF-FORMAT EXTENDED SEARCH (200 BYTES) 

PEE- FORMAT EXTENDED SEARCH (200 BYTES) 

END OF EXTENT APPENDAGE (l 68 BYTES) 

CHECK MODULE (240 BYTES) 



READ /WRITE MODULE (1568 BYTES) 

CE & AE APPENDAGES (2744 BYTES) 

SANDERS 720 DDM (312 BYTES - MODIFIED) 




.'■1 



A 5 

if 

A 



t 




131 



- 139 - 



